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SECTION  1.  GENERAL 


1.1  Purpose  of  the  Subsystem  Specification.  The  Subsystem  Specification  for  the 
Headquarters,  United  States  Air  Force  (HQ  USAF)  site  of  the  Air  Force  Integrated 
Readiness  Measurement  System  (AFIRMS),  (Contract  No.  F49642-83-C-0022),  is  written 
to  fulfill  the  following  objectives: 

a.  To  provide  a  detailed  definition  of  the  HQ  USAF  subsystem  functions. 

b.  To  communicate  specification  details  of  the  subsystem  functional  requirements. 

c.  To  define  in  detail  the  interfaces  with  other  systems  and  subsystems  and  the 
facilities  to  be  utilized  for  accomplishing  these  interfaces- 

The  subsystem  specification  also  contains,  as  appendices,  the  specifications  for  each 
of  the  products  required  for  subsystem  implementation. 

1.2  Introduction  to  AFIRMS.  This  section  provides  a  brief  introduction  to  AFIRMS.  A 
more  complete  description  is  provided  in  the  AFIRMS  Functional  Description. 


1.2.1  AFIRMS  Synopsis. 

1.2. 1.1  Key  AFIRMS  Concepts.  AFIRMS  is  an  automated,  tasking  based,  capability 
assessment  system.  As  such,  AFIRMS  evaluates  unit  and  force  capability  to  perform 
tasked  missions  based  on  the  availability  of  specific  resources. 


a.  The  conceptual  requirements  for  AFIRMS  are  two-fold: 


( I)  Assessment  of  combat  capability  against  specific  tasking.  The  user  can 
assess  unit/force  combat  capability  against  any  planned  or  ad  hoc  tasking, 
e.g.,  ')lar  Mobilization  Plan  (W.MP),  Operation  Plan  (OPlan),  Fragmentary 
Orde.,  Air  Tasking  Order  (ATO),  Contingency  Plan,  etc. 


(2)  Assessment  of  combat  capability  based  on  budget  appropriations. 

AFIRMS  provides  a  tool  for  computing  long-term  readiness  and 
sustainability  trends,  spanning  two  to  six  fiscal  years.  This  tool  permits 
comparison  of  readiness  and  sustainability  by  fiscal  year  and  can 
therefore  highlight  the  impact  of  appropriation  changes.  Thus,  changes  in 
funding  are  related  to  changes  in  force  readiness  and  sustainability.  Also, 
senior  Air  Force  decision  makers  are  supported  during  budget 
deliberations  and  Air  Force  budget  allocations. 
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b.  AFIRMS  implementation  has  two  key  concepts: 

(1)  Integrated  approach  to  tasking  based  capability  assessments.  AFIRMS  has 
two  integrative  dimensions.  First,  all  applicable  resources  and  their  usage 
interactions  are  considered.  For  example,  in  sortie  capability  assessment, 
AFIRMS  evaluates  capability  in  terms  of  all  four  essential  resource  types 
(aircrew,  aircraft,  munitions,  fuel),  their  interdependencies,  and  their 
generative  components  (such  as  spares  for  aircraft,  training  qualifications 
for  aircrew,  load  crews  for  munitions,  and  hot  pits  for  fuel).  Second, 
other  automated  systems  (such  as  the  Combat  Supplies  Management 
System  (CSMS),  Combat  Fuels  Management  System  (CFMS),  Weapon 
System  Management  Information  System  (WSMIS),  etc.)  outputs  are 
integrated  into  capability  assessment  calculations  through  system 
interfaces  between  those  systems  and  AFIRMS. 

(2)  Data  Quality  Assurance.  Capability  assessment  is  no  better  than  the  data 
upon  which  it  is  based.  Therefore,  AFIRMS  emphasizes  a  user  orientation 
toward  quality  assurance  of  source  data.  Unit  and  other  data  input  level 
users  are  provided  effective  tools  to  accomplish  their  daily  activities  and 
therefore  develop  a  vested  interest  in  AFIRMS  data  currency  and 
validity.  Capability  assessment  data  can  then  be  extracted  for  use  by 
higher  or  parallel  users  with  maximum  confidence  in  its  validity. 


1.2. 1.2  AFIRMS  Functions.  Four  basic  AFIRMS  functions  combine  to  assess  readiness 
capability: 


a.  Translate  Tasking.  As  a  tasking  based  capability  assessment  system,  tasking 
must  be  converted  into  a  standard  format  recognized  by  AFIRMS.  Tasking  is 
defined  in  AFIRMS  to  the  unit  level  and  may  consist  of  actual,  hypothetical, 
standard,  or  contingency  tasking.  Any  of  these  taskings  can  be  defined  within 
specified  WMP  or  OPlan  constraints,  at  the  option  of  the  user.  Likewise,  the 
tasking  may  be  defined  by  the  user  for  present,  historic  or  future  requirements. 

b.  Define  Resources.  The  resource  definition  function  of  AFIRMS  ensures  that 
information  about  inventory  status  is  available  and  accurate.  Wherever 
possible,  this  data  is  obtained  by  interface  with  other  functional  systems.  As 
with  tasking,  resource  information  can  be  defined  for  actual,  hypothetical, 
standard,  or  contingency  situations,  either  present,  historic,  or  future. 

c.  Determine  Ability  to  Perform.  Determining  the  force's  ability  to  perform  is 
the  essential  function  of  AFIRMS.  The  tasking  and  resource  data  are  processed 
to  determine  how  much  of  the  specified  tasking  can  be  accomplished  with  the 
resources  available.  Ability  to  perform  is  evaluated  in  terms  of  the  task  metric 
(sorties, etc.)  and  the  cost  metric  (dollars)  to  provide  readiness/sustainability 
and  dollars  to  readiness  assessments. 

d.  Aggregate,  Analyze  and  Present  Data.  Aggregation,  analysis  and  presentation 
ensure  the  proper  grouping  and  display  of  data  to  provide  useful  information  at 
the  unit,  major  command  and  HQ  U5AF.  Aggregation  refers  to  the  creation  of 
a  composite  understanding  of  capability  for  several  units. 


1.2.2  AFIRMS  Documentation.  A  set  of  nine  types  of  documents  describes 
AFIRMS.  A  list  of  these  AFIRMS  documents  is  provided  below  along  with  a  short 
description  of  the  particular  aspects  of  AFIRMS  which  are  addressed  by  each 
document . 


a.  Functional  Description  (FD).  The  FD  provides  the  description  of 
AFIRMS  concepts  in  user  terms.  It  is  the  baseline  document  which 
ties  the  AFIRMS  documents  together. 

b.  Economic  Analysis  (EA).  The  EA  states  AFIRMS  estimated  costs.  It 
explains  the  cost  factors  of  AFIRMS  implementation  alternatives  and 
states  the  recommended  alternative. 

c.  Management  Plan.  The  Management  Plan  provides  the  top-level, 
integrative  frame  of  reference  for  the  AFIRMS  Program.  The  plan 
focuses  on  the  processes  which  provide  technical  and  administrative 
control  of  AFIRMS.  Key  annexes  to  the  Management  Plan  are  the 
Evolutionary  Implementation  Plan,  the  Configuration  Management 
Support  Plan,  and  the  Systems  Interface  Support  Plan. 

d.  System  Specification.  The  AFIRMS  System  Specification  adds  the 
design  requirements  to  the  functional  concepts  in  the  FD.  It  divides 
the  system  into  subsystems  (HQ  USAF,  HQ  USAFE  (MAJCOM),  and  VJing 
(unit))  and  assigns  functions  required  within  each  subsystem.  The 
system  specification  details  the  overall  architecture,  intersite 
interface  gateways,  processing  logic  flows  and  the  communications 
network,  specifications. 

e.  Subsystem  Specifications.  There  are  three  AFIRMS  subsystem 
specifications:  HQ  USAF,  HQ  USAFE  (MAJCOM/numbered  Air  Force),  and 
the  Wing  (unit/squadron).  Subsystem  specifications  detail  the 
specific  design  and/or  performance  requirements  of  the  system  at  that 
level.  Design  details  cover  the  architecture,  required  functions, 
the  functional  users,  intrasite  interface  gateways,  and  applicable 
processing  logic  flows. 

f.  Database  Specifications.  There  are  three  AFIRMS  database 
specifications:  HQ  USAF,  HQ  USAFE  (MAJCOM/numbered  Air  Force),  and 
Wing  (unit/squadron).  These  specifications  describe  the  database 
architecture,  size  and  content,  as  well  as  logical  data  relationships 
for  the  functions  performed  at  each  of  the  AFIRMS  levels. 

g.  Data  Requirements  Document  (DRD).  The  DRD  identifies,  categorizes, 
and  groups  the  generic  types  of  data  used  in  AFIRMS.  It  also  defines 
each  type  of  AFIRMS  data  element  (attribute  class). 

h.  Product  Descriptions  (PDs).  The  PDs  visually  portray  the  products 
which  implement  the  AFIRMS  functions  as  input  and  output  tools. 
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Transform  and  Model  Descriptions.  The  Transform  and  Model 
Descriptions  Document  defines  how  AFIRMS  calculates  the  output  data 
from  the  input  data.  Specific  algorithmic  calculations  are  provided. 
Logical  groups  of  algorithms  forming  AFIRMS  models  and  transforms  are 
described. 
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1.3  Project  References.  Accurate  assessment  of  force  readiness  and 
sustainability  has  been  a  constant  concern  of  Air  Force  commanders  and  their 
staffs.  This  concern  has  been  supported  by  an  intensified  DoD-wide  interest 
in  capability.  In  response  to  this  Air  Force  concern,  the  Directorate  of 
Operations  and  Readiness  initiated  the  AFIRMS  Program.  AFIRMS  has  been  under 
development  through  a  learning  prototype  and  is  designed  to  provide  Air  Force 
commanders  with  a  complete,  timely,  and  accurate  assessment  of  their 
operational  readiness  and  sustainability.  In  performing  this  function,  AFIRMS 
provides  combat  capability  assessments  to  Air  Force  leaders  at  HQ  USAF,  major 
command  (MAJCOM),  and  wing  levels  of  command  to  aid  them  in  making  total  force 
readiness  decisions.  AFIRMS  also  supports  day-to-day  operations  and  crisis 
management  as  well  as  planning  and  programming  activities  at  all  command 
levels . 

The  Program  Management  Office  (PMO)  responsible  for  contract  management  of 
the  AFIRMS  Learning  Prototype  Phase  (LPP)  and  this  document  is  the  Data 
Systems  Design  Office  (DSDO/XO),  Gunter  Air  Force  Station  (AFS),  Alabama;  the 
Office  of  Primary  Responsibility  (OPR)  is  the  United  States  Air  Force 
Readiness  Assessment  Group  (AF/XOOIM).  Three  operational  centers  have  been  in 
use  as  LPP  testbed  sites:  The  Pentagon,  Washington,  D.C.;  Headquarters, 

United  States  Air  Forces  Europe  (HQ  USAFE),  Ramstein  Air  Base  (AB),  Germany; 
and  the  52nd  Tactical  Fighter  Wing  (TFW),  Spangdahlem  AB,  Germany. 

References  which  are  applicable  to  the  history  and  development  of  the 
AFIRMS  Program  are  listed  below  along  with  references  concerning  programming 
and  documentation  standards. 

a.  AFIRMS  Data  Requirements  Document,  Final,  SofTech,  Contract  No. 

F49642-83-C-0022,  31  May  1985.  (Unclassified) 

b.  AFIRMS  Economic  Analysis,  Final,  SofTech,  Contract  No. 

F49642-83-C-0022,  31  May  1985.  (Unclassified) 

c.  AFIRMS  Management  Plan,  Annex  B,  Evolutionary  Implementation  Plan. 

Final,  SofTech,  Contract  No.  F49642-83-C-0022 ,  31  May  1985. 

(Unclassified) 

d.  AFIRMS  Functional  Description,  Final.  SofTech.  Contract  No. 

F49642-83-C-0022,  31  May  1985.  ( Unc lass i t ied ) 
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e. 


AFIRMS  HQ  USAF  Database  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 


f. 


AFIRMS  HQ  USAF  Subsystem  Specification,  Final,  SofTech, 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 


Contract  No 
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g.  AFIRMS  HQ  USAFE  Database  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

h.  AFIRMS  HQ  USAFE  Subsystem  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

i.  AFIRMS  Product  Descriptions,  Final,  SofTech,  Contract  No.  F49642-83-C-0022, 
31  May  1985.  (Unclassified) 

j.  AFIRMS  System  Specification,  Final,  SofTech,  Contract  No.  F49642-83-C-0022, 
31  May  1985.  (Unclassified) 

k.  AFIRMS  Transform  and  Model  Descriptions,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

l.  AFIRMS  Wing  Database  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

m.  AFIRMS  Wing  Subsystem  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

n.  System  Interface  Design  for  the  AFIRMS  LPP  and  the  Combat  Fuels 
Management  System  (CFMS),  SofTech,  Contract  No.  F49642-83-C-0022, 

28  February  1985.  (Unclassified) 

o.  System  Interface  Design  for  the  AFIRMS  LPP  and  the  Air  Force  Operations 
Resource  Management  System  (AFORMS),  SofTech,  Contract  No. 
F49642-83-C-0022,  2  November  1984.  (Unclassified) 

p.  AFR  700-2,  Information  Systems  Planning,  26  October  1984,  (Unclassified) 

q.  AFR  700-5,  Information  Systems  Requirements  Board,  9  November  1984. 
(Unclassified) 

r.  AFR  205-16,  Automated  Data  Processing  (ADP)  Security  Policy,  Procedures, 
and  Responsibilities,  1  August  1984.  (Unclassified) 

s.  AFR  300-4,  Vol.  4,  Air  Force  Data  Dictionary,  1  May  1984.  (FOUO) 

t.  DoD-STD-7935.1,  Automated  Data  Systems  (ADS)  Documentation  Standards, 

24  April  1984.  (Unclassified) 

u.  JCS  Pub  1,  Department  of  Defense  Dictionary  of  Military  and  Associated 
Terms,  24  April  1984.  (Unclassified) 

V.  AFR  700-1,  Managing  Air  Force  Information  Systems,  2  March  1984. 
(Unclassified) 

w.  AFIRMS  LPP  ADP  Security  Plan,  SofTech,  Contract  No.  F49642-83-C-0022, 

13  February  1985.  (FOUO) 

X.  AFR  300-4,  Vol.  3,  Air  Force  Data  Dictionary,  15  August  1983.  (FOUO) 
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y.  Sustainability  Assessment  Model  (formerly  CAC)  Functional 
Description,  Contract  No.  F33700-83-G-002005701 ,  8  April  1983. 
(Unclassified) 

z.  AFR  700-3,  Information  Systems  Requirements  Processing, 

30  November  1984.  (Unclassified) 

aa.  MIL-STD-480  Configuration  Control-Engineering  Changes,  Deviations, 
and  Waivers. 

bb.  MIL-STD-483  Configuration  Management  Practices  for  Systems, 

Equipment,  Munitions,  and  Computer  Programs. 

cc.  USAF  Operational  Major  Command  Functional  Area  Requirement  (FAR), 
SofTech,  Contract  No.  F49642-82-C-0045 ,  15  December  1982. 
(Unclassified) 

dd.  AFR  55-15,  Unit  Combat  Readiness  Reporting  (C-Ratings)  (Unit  Status 
and  Identity  Report  (UNITREP),  RCS:HAF-XOO(AR)7112(DD) ) , 

22  November  1982.  (Unclassified) 

ee.  USAFE  Annex  to  USAF  FAR,  SofTech,  Contract  No.  F49642-82-C-0045,  20 
August  1982.  (Unclassified) 

ff.  AFIRMS  FAR,  SofTech,  Contract  No.  MDA-903-76-C-0396,  14  March  1980. 
(Unclassified) 

gg.  AFIRMS  Data  Analysis,  SofTech,  15  February  1979.  (Unclassified) 

hh.  User's  View  of  AFIRMS,  SofTech,  1  November  1978.  (Unclassified) 

ii.  AFR  700-9,  Information  Systems  Standards,  15  March  1985. 
(Unclassified) 

jj.  AFM  11-1,  Vol.  1,  U.S.  Air  Force  Glossary  of  Standardized  Terms, 

2  January  1976.  (Unclassified) 

kk.  AFIRMS  Data  Automation  Requirement  (DAR),  Final,  SofTech,  Contract 
No.  MDA-903-76-C-0396,  14  March  1980.  (Unclassified) 

11.  JCS  Memorandum  of  Policy  #172,  1  June  1982.  (Unclassified) 

mm.  Federal  Information  Processing  Standards  Publication  (FIPS  PUB)  1. 

nn.  FIPS  PUB  15,  Section  1. 

00.  Military  Airlift  Command  (MAC)  AFIRMS  Requirements  Analysis,  SofTech. 
Contract  No.  F49642-83-C-0022 ,  30  September  1985.  (Unclassified) 

pp.  Analysis  of  Military  Airlift  Command  (MAC)  Capability  Assessment 

Metrics.  SofTech,  Contract  No.  F49642-83-C-0022 ,  30  September  1985. 
(Unclassified ) 
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qq.  Strategic  Air  Command  (SAC)  AFIRMS  Requirements  Analysis,  SofTech, 
Contract  No.  F49642-83-C-0022,  30  September  1985.  (Unclassified) 

rr.  Analysis  of  Strategic  Air  Command  (SAC)  Capability  Assessment 

Metrics,  SofTech,  Contract  No.  F49642-83-C-0022,  30  September  1985 
(Unclassified) 


1.4  Abbreviations  and  Acronyms. 


-  Air  Base 

-  Automated  Data  Processing 
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ADPS 

- 

Automated  Data  Processing  System 

AF 

- 

Air  Force 

AFIRM5 

- 

Air  Force  Integrated  Readiness  Measurement  System 

AFR 

- 

Air  Force  Regulation 

AFS 

- 

Air  Force  Station 

ALC 

- 

Air  Logistics  Center 

ANSI 

- 

American  National  Standards  Institute 

ASCII 

- 

American  Standard  Code  for  Information  Exchange 

ATO 

- 

Air  Tasking  Order 

BPI 

- 

Bits  Per  Inch 

BPS 

- 

Bits  Per  Second 

CAS 

- 

Combat  Ammunition  System 

CBU 

- 

Cluster  Bomb  Unit 

CFMS 

- 

Combat  Fuels  Management  System 

CN 

- 

Central  Node 

CNM 

- 

Central  Node  Module 

CONPLAN 

- 

Concept  Plan 

CPI 

- 

Characters  Per  Inch 

CPL 

- 

Characters  Per  Line 

CPS 

- 

Characters  Per  Second 

CPU 

- 

Central  Processing  Unit 

CRT 

- 

Cathode  Ray  Tube 

CSMS 

- 

Combat  Supplies  Management  SySv;.'n 

DAR 

- 

Data  Automation  Requirement 

DBMS 

- 

Database  Management  System 

DDN 

Defense  Data  Network 

DoD 


Department  of  Defense 


DRD 


Data  Requirements  Document 
DSDO  -  Data  Systems  Design  Office 

EA  -  Economic  Analysis 

EIP  -  Evolutionary  Implementation  Plan 

FA  -  Functional  Area 

FAR  -  Functional  Area  Requirement 

FAW  -  Functional  Area  Workstation 

FD  -  Functional  Description 

FIPS  PUB  -  Federal  Information  Processing  Standards  Publication 

FOUO  -  For  Official  Use  Only 

FTP  -  File  Transfer  Protocol 

HOL  -  High  Order  Language 

HQ  USAF  -  Headquarters,  United  States  Air  Force 

HQ  USAFE  -  Headquarters,  United  States  Air  Forces  Europe 

lAW  -  In  Accordance  With 

I/O  -  Input/Output 

IP  -  Internet  Protocol 

IPS  -  Inches  Per  Second 

ISO  -  International  Standards  Organization 

LED  -  Light  Emitting  Diode 

LPl  -  Lines  Per  Inch 

LPM  -  Lines  Per  Minute 

LPP  -  Learning  Prototype  Phase 

MAC  -  Military  Airlift  Command 

MA3COM  -  Major  Command 

MDS  -  Mission,  Design,  Series 

MICAP  -  Mission  Capable 

North  Atlantic  Treaty  Organization 


NATO 


NBS 

NSA 

OCR 

OPlan 

OPORD 

OPR 

PD 

PMO 

POL 

POM 

PPL 

RM 

SAC 

SCL 

SMTP 

TAP 

TCP 

TFVl 

USAFE 

WIN 

WMP 

WSMIS 


National  Bureau  of  Standards 
National  Security  Agency 
Optical  Character  Reader 

-  Operation  Plan 

-  Operation  Order 

Office  of  Primary  Responsibility 
Product  Descriptions 
Program  Management  Office 
Petroleum,  Oil,  and  Lubricants 
Program  Objective  Memorandum 
Preferred  Products  List 
Deputy  Commander  for  Resources 
Strategic  Air  Command 
Standard  Conventional  Load 

-  Simple  Mail  Transfer  Protocol 

-  Tactical  Air  Force 
Transmission  Control  Protocol 

-  Tactical  Fighter  Wing 

United  States  Air  Forces  Europe 
WWMCCS  Intercomputer  Network 
War  Mobilization  Plan 

Weapon  System  Management  Information  System 
World  Wide  Military  Command  and  Control  System 


WWMCCS 


SECTION  2.  SUMMARY  OF  REQUIREMENTS 


AFIRMS  is  a  tasking  based  capability  assessment  system  that  assesses  readiness  and 
sustainability  by  applying  specific  tasking  (identified  to  accomplish  the  assessments 
desired)  against  selected  unit  and  theatre  resources  through  the  use  of  automated 
assessment  models.  As  a  decision  support  tool,  it  provides  Air  Force  commanders  at  all 
levels  with  the  ability  to  assess  capability  to  meet  a  specific  tasking.  The  requirement 
for  AFIRMS  is  two-fold: 

a.  Assess  capability  against  any  tasking.  The  operator  of  the  system  can  select  a 
tasking  against  which  to  assess,  i.e.,  WMP,  OPlan,  What-if  Plan,  and  Air  Tasking 
Order  (A TO).  AFIRMS  then  provides  a  capability  assessment  against  that 
scenario  in  a  unit  of  measure  appropriate  for  the  tasked  mission.  For  example, 
for  the  Tactical  Air  Force  (TAF),  the  metric  is  the  number  of  sorties  that  can 
be  flown;  for  the  Military  Airlift  Command  (MAC),  the  number  of  ton-miles  or 
the  number  of  flying  hours  that  can  be  flown  may  be  the  metric. 

b.  Correlate  dollar  costs  to  readiness  assessments.  AFIRMS  provides  tools  for 
computing  long-term  readiness  and  sustainability  trends,  spanning  two  to  six 
fiscal  years.  These  tools  compare  readiness  and  sustainability  by  fiscal  year 
and  relate  the  impacts  of  appropriations  by  fiscal  year. 

The  worldwide  operational  AFIRMS  is  a  hierarchically  structured  system  which  can 
be  visualized  as  a  pyramid  of  distinct  operational  sites.  Each  operational  site  performs  a 
set  of  functions  which  are  distinct  from,  although  similar  to,  other  sites  and  transmits 
information  logically  upward  to  a  parent  site.  There  are  three  basic  levels  within  the 
AFIRMS  pyramid,  each  level  being  considered  as  an  AFIRMS  subsystem.  The  highest  level 
subsystem,  the  apex  of  the  pyramid,  is  the  HQ  USAF  subsystem.  The  second  level  of  the 
pyramid  consists  of  the  major  command  (MA3COM)  subsystems.  Each  Major  Command 
contains  at  least  one  AFIRMS  MAJCOM  subsystem;  one  for  the  MAJCOM  HQ,  and  one  for 
each  major  headquarters  in  the  MAJCOM  as  appropriate  (i.e..  Numbered  Air  Force  or  Air 
Logistics  Center).  The  base  of  the  pyramid  is  composed  of  a  set  of  wing  subsystems. 

Each  wing  within  a  MAJCOM  contains  an  AFIRMS  wing  subsystem  which  is  connected  to 
the  parent  MAJCOM. 


2.1  HQ  USAF  Subsystem  Description.  The  HQ  USAF  site  in  the  operational  AFIRMS  is 
the  top-level  entity  in  the  eventual  worldwide  AFIRMS  distributed  network. 


HQ  USAF  tasking  data  consists  of  (but  is  not  limited  to)  WMPs,  OPlans,  Operation 
Orders  (OPORDs),  Contingency  Plans,  and  ad  hoc/what-if  plans  (queries). 
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I 

Resource  data  to  be  used  by  HQ  L'SAF  includes:  Aggregated  wing  information  as 
reported  by  individual  units;  other  in-theatre  resource  information  as  maintained  by  the 
I  MAJCOMs;  and,  out-of-theatre  resupply  information  as  provided  by  HQ  AFLC,  etc. 

This  data  consists  of  information  concerning  munitions,  fuels,  spares,  maintenance 
support,  base  status,  aircraft,  and  aircrew.  It  is  supplied  by  reported  wing  information, 

I  operations,  resource  managers,  and  logistics. 

Assessments  begin  at  the  wing  level  by  collecting  information  on  possessed  resources 
and  the  status  and  capability  of  aircrews,  aircraft,  maintenance  support,  and  base  support 
I  facilities.  This  information  is  compared  against  the  wing's  tasking  to  provide  an 

integrated  look  at  individual  wing  capabilities.  These  individual  wing  capabilities  are 
transmitted  to  the  appropriate  MA3COM,  where  they  are  aggregated  and  then  combined 
with  other  factors  that  are  controlled  at  the  theatre  level,  such  as  Petroleum,  Oil,  and 
Lubricants  (POL),  pipeline  information,  and  munitions  stockage  to  form  a  theatre-wide  or 
VA3COM-level  force  assessment.  MA3COMs  will  then  transmit  this  MA3COM  resource 
and  unit  status  data  to  HQ  USAF  to  produce  total-force  assessments. 

I  AFIRMS  HQ  USAF  level  products  provide  capability  assessment  insights  that  assist  in 

objectively: 

a.  Providing  guidance  and  policy  to  the  MA3COMs. 

b.  Analyzing  resource  needs  and  expenditures. 

c.  Preparing,  defending,  and  administering  the  USAF  budget. 

d.  Obtaining,  controlling,  and  allocating  the  resources  of  manpower,  money,  and 
material  needed  for  support  of  the  combat  forces. 

e.  Assigning  forces. 

f.  Supporting  crisis  and  wartime  decision  making. 


2.1.1  HQ  USAF  Subsystem  Architecture.  The  general  subsystem  architecture  for 


The  centralized  database  is  accessed  via  one  or  more  central  node  modules  (CNVls). 
Each  C.Wl  services  one  or  more  functional  areas  (FAs)  and  shares  the  centralized 
database  with  any  other  CNMs  comprising  the  central  node. 

2. 1.1.1  Central  Node  Modules.  Each  CNM  possesses  the  following: 


a.  A  full  duplex  high  band  width  communications  path  to  each  on-line  storage 
device  that  has  any  part  of  the  centralized  database  resident  upon  it. 

b.  One  or  more  high  band  width  full  duplex  communications  paths  to  one  or  more 
other  CNMs  comprising  the  central  node.  If  only  two  CNMs  comprise  a  central 
node,  two  communications  paths  between  the  two  are  provided. 

c.  One  private  on-line  storage  device  which  contains  the  system  software  for  that 
CNM  and  which  is  used  for  system  storage  space  only. 

d.  A  copy  of  the  DBMS  being  used  for  the  system.  Control  for  updates  of,  and 
retrievals  from,  the  centralized  database  is  distributed  between  the  CNMs. 
Ideally,  the  physical  updates  and  retrievals  themselves  are  also  distributed 
between  the  CNMs. 

Each  CNM  is  responsible  for  updating  the  databases  of  the  FAs  attached  to  it  as 
required.  It  is  also  responsible  for  transmitting  the  data  updates  made  by  one  or  more  of  its 
attached  FAs  to  all  other  CNMs  to  allow  them  to  update  their  FA  databases  as  required. 

2. 1.1.2  Functional  Areas.  Each  FA  has  an  intelligent  device  containing  its  own  database 
and  copies  of  required  software. 

The  data  resident  on  the  FA  database  consists  of  update/read  and  read  only  data 
elements.  The  specific  data  resident  is  determined  by  the  data  needed  for  a  functional 
area's  normal  uses.  See  the  HQ  LiSAF  Database  Specification  for  details  of  the  data 
requirements  by  functional  user.  When  an  update  is  made  at  the  FA,  the  update  transaction 
is  sent  to  the  central  node  to  allow  update  of  the  centralized  database  and  for 
synchronization  of  the  databases  of  other  FAs. 


2. 1.1.3  Communications.  A  communications  path  is  provided  for  normal  communications 
between  a  FA  device  and  a  CNM.  In  addition  to  this  normal  channel,  each  FA  has  an 
alternate  temporary  path  of  communications  (i.e.,  a  dial-up  phone  line).  Each  CNM  has  the 
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2.2  HQ  USAF  Subsystem  Functions.  Three  levels  of  functions  are  of  interest  in  this  HQ 
USAF  subsystenn  specification.  They  are:  Basic  AFIRMS  Functions,  Secondary  AFIRMS 
Functions,  and  System  Functions. 

a.  Basic  AFIRMS  Functions.  The  building  block  functions  which  are  specific  to 

AFIRMS  and  which  are  used  (in  different  forms  and  combinations)  to  providethe 
user  with  various  types  of  data/information.  The  Basic  AFIRMS  Functions  at 
the  HQ  USAF  level  are: 

(1)  Translate  Tasking.  Translates  tasking  in  its  many  forms  (OPlans,  Concept 
Plans  (CONPLANs),  etc.)  into  specific  resource  requirements  (mission 
types,  aircraft  type,  and  configuration,  munitions  load,  etc.)  to  be  used  in 
measuring  ability  to  perform.  The  Translate  Tasking  function  will  assist 
in  task  assignment  and  forecast  results  of  trial  or  final  assignments.  HQ' 
USAF  level  products  that  use  this  function  include: 

(a)  Aircraft  Tasking 

(b)  Mission  and  Aircraft  Tasking  Details 

(c)  Mission  Area  Tasking 

(d)  Mission  Profile  Definition 

(e)  Mission  Tasking 

(f)  Order  Assignments 

(g)  War  Mobilization  Plan 

(h)  Wing  Flying  Day 

(i)  W  ing  Operations  Rates 

(2)  Define  Resources.  Provides  inventory  status  and  availability  of  resources 
(such  as  fuels,  munitions,  aircraft,  and  aircrews)  for  use  in  capability 
assessment.  The  Define  Resources  function  will  assist  in  allocation  of 
resources  (physical  or  fiscal)  and  forecast  results  of  trial  or  final 
allocations.  In  addition,  it  can  assist  in  out-year  budget  plans  (dollars  to 
readiness)  by  forecasting  results  of  trial  or  final  allocations  based  on 
standard  or  user-supplied  assumptions.  HQ  USAF  level  products  that  use 
this  function  include: 

(a)  Dollars  to  Readiness;  i.e.: 

Dollars  to  Readiness  -  Comparisons 
Dollars  to  Readiness  -  Resource  Perspective 
Resource  Unit  Price 

(b)  Munitions  Status 

(c)  Resource  Reallocation 

(d)  Resupply  Schedule 

(e)  W  ing  Resource  Summary 


(3)  Determine  Ability  to  Perform.  Given  current  and  forecast  readiness 

factors,  AFIRMS  transforms  WMPs,  ATOs,  OPlans,  and  what-if  exercises 
into  measurable  tasking;  computes  current  capability  to  perform,  the  task, 
projects  capability  into  the  future;  and  calculates  resources  consumed  by 
performing  the  task.  This  function  will  provide  users  with  the  capability 
to  measure  (and  aggregate)  readiness  and  sustainability  vs.  standard  or 
one-time  tasking,  and  measure  (and  aggregate)  readiness  or  sustainability 
vs.  revised  standards,  and/or  revised  standard  tasking  using  historic  data. 

HQ  L'SAF  level  products  that  use  the  Determine  Ability  to  Perform 
function  include: 

(a)  Aircraft  Spares  Support  Capability 

(b)  Base  Fuels  Capability 

(c)  Capability  Perspective 

(d)  Fuels  Capability 

(e)  Individual  Resource  Capability 

(f)  Integrated  Capability 

(g)  Munitions  Capability 

(h)  Sortie  Generation  Model 

('*)  Aggregate,  Analyze  and  Present  Data.  This  function  deals  with  the  task 
of  properly  grouping  data  from  various  wings  to  provide  meaningful  and 
useful  data  at  MA3COM  and  HQ  IJSAF  levels.  It  also  develops  trend  and 
variance  data  to  facilitate  exception  type  reporting  on  unusual 
developments  in  day-to-day  data. 

Aggregation  refers  to  the  creation  of  a  composite  understanding  of  the 
readiness  and  sustainability  of  a  number  of  units.  Thus,  a  .MA3CQM  with 
many  reporting  wings,  each  with  its  own  deficiencies  and  strengths,  can 
assess  the  readiness  (and  sustainability)  of  all  units  taken  as  a  whole. 

HQ  U5AF  level  products  that  use  the  Aggregate,  Analyze,  and  Present 
Data  function  include: 

(a)  Attritition  Trends 

(b)  Base  Status 

(c)  Capability  Perspective 

(d)  Communications  Support  Status 

(e)  Vlunitions  Substitution  Sortie  Capability 

(f)  Munitions  Substitution  Sortie  Requirement 

(g)  Status  Map 

(h)  Unit  Status 


b.  Secondary  AFIRMS  Functions.  In  order  to  carry  out  the  Basic  AFIRMS 
Functions,  AFIRMS  must  maintain  and  verify  data.  To  help  ensure  the  accuracy 
of  the  data  and  to  take  advantage  of  its  availability,  AFIRMS  provides  a  variety 
of  associated  capabilities  which  are  not  directly  related  to  capability 
assessment.  These  functions  are  secondary  and  some  of  them  may  be 
eliminated  if  the  circumstances  in  which  AFIRMS  operates  were  to  change. 
Examples  of  these  secondary  functions  are:  display  tasking;  perform  ad  hoc 
queries;  and  display  information  on  an  evolving  schedule.  For  a  detailed  listing 
of  these  functions,  refer  to  the  AFIRMS  System  Specification. 

c.  System  Functions.  The  standard  building  block  functions  such  as  graphics  or 
data  mangement  which  might  occur  in  any  system,  and  which,  together  with 
specially  written  subfunctions,  are  used  to  support  the  Basic  and  Secondary 
AFIRMS  Functions.  For  a  detailed  listing  of  these  functions,  refer  to  the 
AFIRMS  System  Specification. 


2.2.1  Accuracy  and  Validity.  The  accuracy  of  the  AFIRMS  database  is  essential  for  the 
generation  of  accurate  measurements.  There  are  two  categories  of  accuracy  and  validity 
that  must  be  addressed.  The  first  is  related  to  electronic  manipulation,  storage,  and 
transmission  of  data  in  the  AFIRMS  system.  The  second  is  related  to  the  interface 
between  the  user  or  other  Air  Force  systems,  and  the  AFIRMS  system. 


a.  Electronic  Manipulation/Storage/Transmission. 

(1)  The  nature  of  the  models/displays  created  with  AFIRMS  does  not  require 
precision  beyond  that  achievable  with  off-the-shelf  standard  micro  or 
minicomputers  that  support  hardware  or  software  floating  point 
computations. 

(2)  Errors  in  data  transmissions  will  not  exceed  1  part  in  10^.  Parity 
checking  and  cyclical  redundancy  checking  (CRC)  ensure  that  the  data 
actually  used  internal  to  the  AFIRMS  sites  has  an  error  probability  well 
below  this  figure  by  correcting  all  1-bit  errors.  (Double-bit  errors  are 
detected  but  not  corrected.) 

b.  User  Interfaces  to  AFIRMS.  The  user  interfaces  of  interest  are  those 
interfaces  that  introduce  new  information  into  AFIRMS.  The  concern  is  that 
the  information  destined  to  enter  the  database  be  valid.  Valid  here  means  that: 

( 1)  The  individual  entering  the  information  is  authorized  to  do  so  (i.e.,  only 
logistics  personnel  may  be  authorized  to  update  logistics  information, 
using  logistics  data  forms), 

(2)  The  information  is  as  "error  free  as  possible."  This  suggests  that  input 
data  must,  in  general,  be  entered  through  well-engineered  interfaces  that 
prompt  the  user  and  check  field  contents. 
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(3)  Certain  infornnation  passed  into  the  database  has  sufficient  criticality  to 
require  verification  beyond  that  identified  in  (2)  above,  prior  to  database 
updates.  This  verification  occurs  via  supervisory  review.  Under  this 
method,  the  data  is  entered  by  an  authorized  individual.  However,  the 
information  cannot  update  the  database  or  be  transmitted  to  higher 
headquarters  by  the  individual  who  entered  it  until  a  supervisor  authorizes 
the  AFIRMS  system  to  accept  the  data.  The  method  of  authorization 
might  require  that  the  supervisor  log  on  to  the  AFIRMS  system  and  enter 
an  "unlocking"  command  that  allows  the  data  to  be  entered  and  the 
database  updated.  Information  requiring  supervisory  review  is  kept 
minimal.  Specific  data  requiring  this  quality  assurance  technique  are 
identified  during  the  Analysis  Phase  of  each  functional  block 
implementation. 

c.  System  Interfaces  to  AFIRMS.  Data  obtained  by  intelface  with  other  data 
systems  is  subject  to  the  same  data  accuracy  and  validity  criteria  as  for  user 
input  data. 

2.2. 1.1  Data  Accuracy.  AFIRMS  uses  five  main  approaches  to  ensure  the  accuracy  and 
currency  of  data. 

a.  Provide  benefits  to  the  organizations  which  input  readiness  data.  If  the 
organization  which  inputs  data  receives  benefits  from  the  system,  then  it  is 
motivated  to  ensure  that  data  entered  is  current  and  accurate. 

b.  Simplify  data  input  by  using  simple  devices  and  by  grouping  inputs.  For 
example,  a  bar  code  reader  is  a  candidate  device  for  entering  a  complex 
identification  number  that  might  be  subject  to  error  if  entered  via  keyboard. 

c.  Use  automated  edit  check  as  well  as  checks  for  the  reasonableness  of  input  data 
against  stored  parametric  values.  That  is,  all  inputs  are  programmatically 
edited  to  further  ensure  the  accuracy  and  integrity  of  the  database.  The 
system  validates  length,  format,  and  legal  values  of  all  formatted  alphanumeric 
input  data. 

d.  Review/check  all  data  entry  information  for  consistency  against  other  related 
information. 

e.  Obtain,  eait,  and  incorporate  data  and/or  assessments  from  other  automated 
systems. 


2.2.2  Timint 


a.  User  Response  Time.  AFIRMS  is  an  information  processing  system  which  is 
user  intensive;  that  is,  in  general,  users  enter  data  through  a  data  capture 
device  and  request  readiness  status  onto  an  output  di'^olay.  Thus,  it  is 
imperative  that  AFIRMS  response  time  to  user  requests  be  kept  minimal. 
Response  time  as  it  applies  to  user  terminals,  consists  of  two  parts;  comrnana 
acceptance  and  command  execution. 


(1)  Command  Acceptance.  Command  acceptance  is  the  time  between  the 
user's  initiating  transmission  of  a  command  or  transaction  to  the  system 
(such  as  by  depression  of  the  ENTER  key  or  entry  of  the  last  character  of 
a  menu  response)  and  the  appearance  of  the  first  line  of  the 
acknowledgement  from  the  system  on  the  user's  terminal  that  the 
message  has  been  received  or  an  error  condition  exists.  AFIRMS,  under 
loaded  conditions  (more  than  85%  of  terminals  in  use)  supports  a  command 
acceptance  time  of  less  than  2.5  seconds  90%  of  the  time.  At  no  time 
does  command  acceptance  time  exceed  six  seconds. 

(2)  Command  Execution.  Command  execution  is  the  elapsed  time  between 
the  command  or  transaction  entry,  and  the  appearance  of  the  first  line  on 
the  user's  display  terminal  (excluding  graphics). 

(a)  For  functions  such  as  command  entry,  text  editing  or  message 
writing  applications,  the  appearance  of  a  keyed  character  on  the 
screen  is  immediate  in  the  perception  of  the  user. 

(b)  Queries.  AFIRMS  allows  for  local  (intrasite)  queries  only,  with 
response  times  as  follows: 

_[  Simple.  Response  time  of  1  to  3  seconds. 

2  Medium.  Response  time  of  4  to  10  seconds. 

3  Complex.  Response  time  of  1  1-30  seconds. 

Categorization  of  specific  queries  within  these  definitions  is 
accomplished  during  the  Analysis  Phase  of  the  functional  block 
developments.  These  times  do  not  include  sortie  generation  model, 
dollars  to  readiness  model,  or  similar  model  execution  times. 

Data  Currency.  Vl'hen  changes  are  made  to  data  at  the  functional  area  level, 
those  changes  are  transmitted  to  the  central  site  database.  After  the  central 
database  is  updated,  the  changes  are  subsequently  transmitted  to  other 
functional  areas  having  the  data  in  question  resident  on  their  local  database. 

The  time  that  it  takes  to  complete  the  transactions  on  the  central  database  and 
all  affected  functional  areas  designates  the  currency  of  data  at  the  site. 

(1)  Mission-Related  Data  -  Within  a  site  this  time  period  must  be  less  than 

three  minutes  for  mission-related  data  90%  of  the 
time  with  the  system  operating  in  a  normal  mode. 
AFIRMS  mission-related  data  consists  of  current 
tasking  and  current  primary  resource  status 
information  or  that  data  associated  with  a  crisis 
mode.  Primary  resources  are  those  resources 
directly  utilized  by  the  capability  assessment 
model. 


(2)  \on-\Ussion-Related  Data  -  Data  currency  within  a  site  must  be  achieved 

within  one  hour  for  non-mission-related  data 
90%  of  the  time  with  the  system  operating  in  a 
normal  mode.  AFIRMS  non-mission-related  data 
consists  of  that  information  relating  to  ad  hoc, 
historic,  exercise,  or  contingency  simulations 
which  neither  relate  to  the  current  situation  nor 
are  designated  as  crisis  mode  items. 

c.  Data  Age.  The  maximum  time  span  allowed  for  known  data  updates  between  HQ 
USAFE  (\lA3COM)  and  HQ  USAF  sites  is  six  hours,  regardless  of  state  of  change 
for  the  data. 


2.3  Flexibility.  AFIRMS  provides  an  architecture  that  matches  the  specific  requirements 
of  HQ  USAF  to  an  AFIRMS  site  with  compatible  hardware/software  capability. 
Additionally,  it  has  the  capability  to  grow,  i.e.,  add/change  system  focus  as  time  passes. 
Capabilities  incorporated  for  adapting  the  HQ  USAF  subsystem  to  changing  requirements 
include  the  following; 


a.  Configuration  of  AFIRMS  sites  from  modular  hardware  and  software 

components.  The  modular  applications  software  is  written  in  Department  of 
Defense  (DoD)  standard  host  independent  high  order  languages  (HOL)  for  ease 
of  transportability  among  different  hardware  configurations.  Acceptable  HOLs 
are  ADA,  C,  or  other  strongly  typed  languages  which  support  modular  software 
design,  readability  and  increased  maintainability. 

0.  A  hardware/software  building  block  approach,  coupled  with  transportable 
software,  to  facilitate  expansion  of  operational  AFIRMS  in  the  future. 

c.  L  tilization  of  DoD  standardized  data  communications  protocols  and  external 
user  interfaces.  AFIRMS  implements  DoD  standard  protocols  for  network  and 
distributed  system  data  communications  and  terminal  interfaces.  Utilization  of 
the  DoD  standard  protocols  provides  for  interoperability  among  different 
vendor  equipments,  existing  and  developmental  Air  Force  Automated  Data 
Processing  (ADP)  systems,  and  is  in  accordance  with  Air  Force  policy  and 
guidance. 

d.  Ability  to  interface  an  AFIRMS  site  to  other  Air  Force  systems  after  the 
AFIRMS  site  has  been  designed  and  installed.  AFIRMS  software  is  structured  so 
as  to  provide  for  new  system  integration  to  the  greatest  extent  possible.  This  is 
facilitated  by  maintaining  distinct  layers  of  software,  as  in  the  International 
Standards  Organization  (ISO)  7-layer  Reference  Model,  and  by  the  use  of 
controlled  standardized  data  gateways  (intersite  or  intrasite  standard  data 
communications  formats). 


e. 


Ability  to  support  secondary  (or  backup)  interfaces,  by  which  an  intermediate 
AFIRMS  site  may  be  bypassed.  For  example,  the  ability  of  a  wing,  in  place  or 
deployed,  to  bypass  the  MA3COM  and  communicate  directly  with  HQ  USAF. 


SECTION  3.  ENVIRONMENT 


3.1  Equipment  Environment.  Equipment  is  provided  to  HQ  USAF  (and  all  other  AFIRMS 
sites)  on  an  "as  needed"  basis.  AFIRMS  uses  existing  facilities  and  equipments  wherever 
possible.  However,  at  a  minimum,  each  AFIRMS  site  contains  the  equipment  required  for 
the  Central  Node  and  one  Functional  Area  workstation.  The  Central  Node  contains  the 
AFIRMS  database  for  that  site  as  well  as  the  communications  support  for  site  to  site 
communications. 

AFIRMS  utilizes  standard  Air  Force  equipment  sources  such  as  the  Air  Force 
Standard  Multiuser  Small  Computer  initiative  by  the  Air  Force  Computer  Acquisition 
Center,  TEMPEST  and  Phase  IV  Program  equipment  sources.  AFIRMS  is  designed  to  allow 
for  the  integration  of  different  computers,  peripherals,  and  communications  standards 
throughout  the  system.  This  provides  for  a  faster  and  more  cost  effective  AFIRMS 
development,  and  a  higher  degree  of  operational  flexibility. 


3.1.1  Central  Node  Equipment.  Each  AFIRMS  site  contains  a  Central  Node  consisting  of 
the  following  equipment; 


a.  One  or  more  processors,  each  capable  of  handling  four  or  more  functional 
areas.  Each  processor  is  a  32-bit  machine  with  at  least  a  24-bit  address 
structure.  Each  processor  has  several  high  bandwidth  full  duplex 
communications  paths  to  the  other  processors,  if  any,  in  the  central  node.  Each 
processor  has  the  ability  to  connect  three  or  more  terminals. 

b.  One  or  more  direct  access,  high  speed  storage  devices  capable  of  containing  the 
centralized  data  base  and  capable  of  being  logically  accessed  by  multiple 
processors.  Each  high  speed  storage  device  has  at  least  one  high  bandwidth  full 
duplex  communications  path  to  each  of  the  processors  in  the  central  node. 

c.  One  direct  access,  high  speed  storage  device  capable  of  containing  all  software 
and  system  files  for  each  processor  in  the  Central  Node. 

d.  A  mass  storage  device,  i.e.  9-track  tape  or  optical  storage  device,  capable  of 
being  accessed  by  multiple  processors. 


e.  A  communications  controller  capable  of  handling  all  external  communications 
lines  and  capable  of  being  accessed  by  multiple  local  processors. 


Encryption  devices  for  each  physical  line  that  may  pass  classified  data.  The 
encryption  device  is  able  to  operate  in  a  synchronous  or  asynchronous  mode  and 
to  operate  at  the  speeds  identified  in  Section  3.1.4  of  this  subsystem 
specification,  "Communications  Equipment". 
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Power  conditioning  and  failure  protection  mechanisms  are  required  as  stated  in 
Section  3. 1.5.2  of  this  subsystem  specification,  "Electrical  Power."  All  "wall 
power"  must  be  filtered  to  protect  equipments  against  power  surges.  Filtered 
power  is  also  required  for  systems  that  process  classified  data  to  prevent  data 
emanations.  Power  failsafe  backup  provisions  are  provided  to  preserve  memory 
in  the  event  of  power  failure.  Backup  power  terminates  during  normal 
shutdown. 


h.  A  CRT  terminal  and  line  printer  for  system  maintenance  and  operator  use. 


Main  Memory.  An  initial  user  memory  capacity  of  a  minimum  of  four 
megabytes  of  user  memory  is  required.  This  user  memory  is  expandable  (in 
minimum  51 2K  byte  increments)  up  to  at  least  10  megabytes.  All  memory 
specifications  are  made  in  8-bit  bytes.  The  physical  organization  of  the  main 
memory  is  modular  so  that  a  failure  in  one  module  (except  the  module 
containing  the  operating  system  or  similar  support  software)  does  not  deprive 
the  system  of  the  remaining  memory.  Memory  must  be  byte  addressable  and 
volatile. 


(1)  Error  Detection.  Asa  minimum,  a  memory  error  detection  and  correction 
feature  are  provided  that  detect  double  bit  errors  and  correct  ail  single 
bit  errors  for  each  byte  of  memory. 

(2)  Memory  Protection.  The  capability  to  inhibit  any  attempt  by  an 
applications  program  to  write  into  or  read  from  mernory  areas  not 
allocated  to  that  program  is  required. 


3.1.2  Functional  Area  Equipment.  Each  functional  area  which  needs  to  access,  enter,  or 
modify  AFIR.MS  data  is  provided  with  a  functional  area  workstation  to  communicate  with 
the  Central  Node.  Each  functional  area  workstation  contains  the  following  equipment: 


a.  One  processor  capable  of  handling  one  or  more  users  depending  on  the  needs  of 
the  functional  area.  The  processor  is,  at  a  minimum,  a  16-bit  machine. 

b.  One  direct  access,  high  speed  storage  device  capable  of  containing  the  local 
database  and  the  software/system  files. 

c.  A  mass  storage  device,  i.e.,  floppy  disk  drive. 


d.  A  communications  controller  capable  of  handling  all  external 
asynchronous/synchronous  communications  between  the  functional  area 
workstation  and  the  central  node. 

e.  Several  miscellaneous  input/output  devices.  The  number  of  each  type  of  device 
depends  on  the  requirements  of  the  functional  area,  and  is  be  determined  during 
the  Analysis  Phase  that  precedes  implementation  at  each  site. 


An  encryption  device  for  communicating  with  the  Central  Node  if  the 
workstation  is  to  handle  classified  data.  The  encryption  device  is  able  to 
operate  either  in  a  synchronous  or  asynchronous  mode  and  to  operate  at  the 
speeds  reauired  by  the  communications  lines. 
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g.  Power  conditioning  and  failure  protection  mechanisms  are  required.  A]J  "waJJ 
power"  must  be  filtered  to  protect  equipments  against  power  surges.  Filtered 
power  is  also  required  for  systems  that  possess  classified  data  to  prevent  data 
enrianations.  Power  failsafe  backup  provisions  are  provided  to  preserve  memory  in 
the  event  of  power  failure.  Backup  power  must  terminate  during  normal  shutdown. 

h.  Main  Memory.  An  initial  user  memory  capacity  of  a  minimum  of  two  megabytes 
of  user  memory  is  required.  This  user  memory  is  expandable  (in  minimum  51  2K 
byte  increments)  up  to  at  least  8  megabytes.  All  memory  specifications  are  made 
in  S-bit  bytes.  The  physical  organization  of  the  main  memory  is  modular  so  that  a 
failure  in  one  module  (except  the  module  containing  the  operating  system)  shall 
not  deprive  the  system  of  the  remaining  memory. 

( 1)  Error  Detection.  As  a  minimum,  a  memory  error  detection  and  correction 
feature  is  provided  that  detects  double  bit  errors  and  corrects  all  single  bit 
errors  for  each  byte  of  memory. 

(2)  Memory  Protection.  The  capability  to  inhibit  any  attempt  by  an 
applications  program  to  write  into  or  read  from  memory  areas  not  allocated 
to  that  program  is  required. 


3.1.3  Input/Output  Devices.  HQ  USAF  device  requirements  for  CRT  terminals,  printers, 
disk  drives  and  magnetic  tape  drives  are  determined  during  the  Analysis  Phase  of  each 
block  implementation. 


a.  CRTs  must  possess  the  following  characteristics; 

(1)  Monochrome  Terminals:  Alphanumeric  keyboard  and  video  display; 
interface  via  standard  RS-232-C  port;  ability  to  function  as  a  system 
console;  and  sound  an  audible  tone  or  "BEEP"  when  the  ASCII  "BEL" 
character  or  its  equivalent  is  received. 


(a)  Keyboards  must  possess  the  following  characteristics: 


j_  Be  capable  of  generating  the  ASCII  128-character  subset  in 
accordance  with  (lAVl)  FIPS  PUB  1. 

2  At  a  minimum,  conform  to  the  ANSI  Standard  X'*. 14-1971. 

3  Have  a  repeat  function  for  all  printable  ASCII  characters, 
cursor  controls,  and  spacing  functions. 

4  Have  separate  keys  for  carriage  return,  control,  escape,  and 
spacing  functions. 


5  Have  a  minimum  of  16  programmable  function  keys. 

6  Have  a  numeric  keypad  to  the  right  of  the  character  keys  and 
allow  numeric  entries  from  either  the  regular  character  key  or 
the  numeric  keypad. 

2  Have  at  least  four  cursor  movement  keys  separate  Iron' 
function  keys. 
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8  Have  a  detachable  keyboard. 

9  Have  a  (screen)  hardcopy  function. 

(b)  Video  Displays  must  possess  the  following  characteristics: 

Display  a  minimum  of  24  lines  of  132  characters  each. 

2  Characters  displayed  consist  of  the  ASCII  95-character  subset 
lAW  FIPS  PUB  15,  Section  1. 

3  If  the  dot  matrix  character  generation  technique  is  used,  the 
matrix  must  be  at  least  7x9. 

4  Full  descenders  will  be  used  on  the  lower  case  such  as  "g,  j,  p, 
q,  y"  and  appropriate  special  characters. 

5  Implement  a  visible  cursor  denoting  the  next  character 
position  in  such  a  manner  that  its  location  is  obvious  to  the 
operator  and  does  not  obscure  any  information  (excluding 
underline)  which  may  be  displayed  at  that  position. 

6  The  cursor  must  be  addressable  and  the  capability  must  be 
provided  for  the  applications  program  to  clear  the  display  and 
to  position  the  cursor  at  any  location  on  the  screen. 

7  Have  a  non-glare  viewing  surface. 

S  Provide  reverse  video,  bold,  blink,  and  underscore  capabilities 
under  application  program  control. 

9  Brightness  must  be  externally  adjustable  by  the  terminal 
operator. 

I  0  The  display  must  be  green  or  amber. 

I I  Have  selectable  terminal  transmission  rates  of  300,  120G, 
2400,  4800,  and  9600  bits  per  second  bits  per  second  (BPS). 

1 2  Have  a  minimum  1  1-inch  screen  measured  diagonally. 

1  3  Have  smooth  scrolling  capability. 

1 4  Support  shading  and  marking  patterns  (prcprogranimcd  ana 

programmable). 

(c)  Other  Required  CRT  Terminal  Characteristics: 

2  Local  memory 

2  Built-in  diagnostics  and  testing 


3  TENIPEST  certified  -  for  terminals  which  display  classified 
information 

4  Screen  print  function 

(2)  Color  Graphics  Terminals  must  possess  the  following  characteristics: 

(a)  Minimum  of  16  special  function  (programmable)  keys.  Refer  to 
Table  3-1  for  some  of  the  required  function  key  features. 

(b)  10%  of  the  terminals  require  a  video  interface  board  for  use  with 
video  projectors 

(c)  Screen  definition  of  not  less  than  720x484  individually  addressable 
and  color  definable  pixels  (i.e.,  medium  resolution) 

(d)  Minimum  1  1"  CRT  screen 

(e)  TEMPEST  certified  -  for  terminals  which  display  classified 
information 

(f)  Support  9600  baud  rate 

(g)  Display  a  minimum  of  16  colors 

(h)  Screen  print  function 

Printers  must  possess  the  following  characteristics; 

(1)  Letter  Quality  Printers  must: 

(a)  Print  at  least  55  characters  per  second  (CPS). 

(b)  Print  at  least  132  characters  per  line  (CPL). 

(c)  Have  a  pressure-feed  mechanism,  interchangeable  tractor  feed  and 
an  automatic  single  sheet  feeder. 

(d)  Print  the  complete  95  character  ASCII  subset  lAW  FIPS  PUB  15, 
Section  1. 

(e)  Have  operator  selectable  print  spacing  of  10  pitch,  12  pitch,  and 
proportional  spacing. 

(f)  Accept  forms  from  4  1/2  to  at  least  14  7/8  inches  in  width. 

(g)  Print  clearly  up  to  3  part  paper. 

(h)  Interface  via  RS-232-C  serial  port  and  parallel  port. 

(i)  Provide  at  least  one  font  which  is  readable  by  an  optical  character 
reader(OCR). 

(|)  Provide  clearly  marked  vertical  and  horizontal  forms  alignment  that 
indicate  the  standard  first  print  position. 


(k)  Have  operator  controls  for  power  online/offline,  advance  to  top  ol 
form  and  manual  adjustment  of  vertical  and  horizontal  paper 
alignment. 

(l)  Be  TEMPEST  certified,  when  used  for  classified  informiation 
printout. 

Dot  Matrix  Printers  must  possess  the  following  characteristics: 

(a)  Print  at  least  200  CPS  at  132  characters  per  line  at  10  characters 
per  inch  (CPI). 

(b)  Have  dot  addressable  graphics  with  a  minimum  resolution  of  70  dots 
per  inch,  vertical  and  horizontal. 

(c)  Provide  correspondence  quality  print  capability  of  at  least  ^0  CPS 
at  10  CPI. 

(d)  L  se  an  operator  adjustable  pin  feed  tractor  for  positive  form 
registration  movement. 

(e)  Print  the  complete  95  character  ASCII  subset  lAVX  FIPS  PUB  1  5, 
Section  1. 

(f)  Accept  forms  ranging  from  4  1/2  to  14  7/8  inches  in  width. 

(g)  Print  full  descenders  used  on  the  lower  case  characters  "g,  j,  p,  q,  y" 
and  appropriate  special  characters. 

(h)  Print  6  and  8  lines  per  inch  (LPl),  operator  selectable. 

(i)  Print  clearly  using  up  to  3  part  paper. 

(j)  Have  controls  for  power,  online/of f line,  advance  to  top  of  form  and 
manual  adjustment  of  vertical  and  horizontal  paper  alignment. 

(k)  Provide  clearly  marked  vertical  and  horizontal  forms  alignment  that 
indicate  the  standard  first  print  position. 

(l)  Provide  program  control  of  line  feed  and  form  feed. 

(m)  Interface  via  RS-232-C  serial  port  and  parallel  port. 

(n)  Be  TEMPEST  certified. 

High  Speed  (Line)  Printers  must  possess  the  following  characteristics: 

(a)  Print  at  least  500  lines  per  minute  (LPM)  (at  1  32  CPU)  using  the 
character  set  specified  in  (b)  below. 

(b)  Print  the  complete  95  character  ASt'II  subset  lAVl  FIPS  PL  B  1  5, 
Section  1. 

(c)  Support  horizontal  spacing  of  10  or  1  2  ('PI. 


(d)  Have  vertical  spacing  of  6  or  8  LPI  switch  or  programmer  selectable. 

(e)  Print  at  least  132  characters  per  line. 

(f)  Print  clearly  up  to  3  part  paper. 

(g)  Have  vertical  format  control  via  programmer  or  printer. 

(h)  Be  TEMPEST  certified. 

(i)  Have  a  diagnostic  light  emitting  diode  (LED)  indicator  for  status. 

(j)  Interface  via  RS-232-C  serial  port  and  parallel  port. 

(4)  Color  Graphics  Printers  must  possess  the  following  characteristics: 

(a)  Plot  the  displayed  graph  in  the  same  ratio  (horizontal  to  vertical)  as 
the  screen  display,  in  no  more  than  90  seconds. 

(b)  Provide  minimum  resolution  of  100x85  horizontal  to  vertical  dots  per 
inch. 

(c)  Print  at  least  eight  colors. 

(d)  Print  on  bond  paper  and  transparency  (developing  of  transparency  not 
acceptable). 

(e)  Interface  via  RS-232-C  serial  port  or  parallel  port. 

(f)  Accept  a  minimum  paper  size  of  8.5x11  inches. 

Floppy/.Microfloppy  Disk  Drives  must  possess  the  following  characteristics: 

( 1)  Minimum  of  two  read/write  heads  to  provide  access  to  double-sided  disks. 

(2)  Provide  a  formatted  storage  capacity  for  one  diskette  of  at  least  1.5 
megabytes. 

(3)  Use,  at  a  minimum,  a  5.25  inch  double  sided/double  density  diskette  for 
floppy  disk  drives  and  3.5  inch  diskette  for  microfloppy  disk  drives. 

(4)  Be  compatible  with  FA  workstation  hardware  selection. 

Magnetic  Tape  Drives  must  possess  the  following  characteristics: 

( 1)  Be  nine  (9)  track. 

(2)  Support  a  10.5  inch  reel  of  .5  inch  by  2400  foot  standard  reel  tape. 

(3)  Support  speed  read/write  operations  at  a  minimum  of  75  inches  per  second 
(IPS),  streaming  at  a  minimum  of  200  IPS. 

(4)  Perforrn  error  checking  on  all  read  operations. 


(5)  Perform  a  read  after  write  with  error  checking  on  all  write  operations. 

(6)  Have  write  protection  and  beginning  and  end  of  tape  sensor. 


(7)  Support  a  minimum  of  dual-density  (1600/6250  bits  per  inch  (BPl))  tape 
read  and  write  capability. 


3.1.4  Communications  Equipment.  Requirements  for  specific  types  and  quantities  of 
communications  hardware  are  determined  during  the  analysis  phase  that  precedes 
implementation  of  each  functional  block  at  each  site. 


3. 1.4.1  Primary  Intrasite  Communications.  Primary  communications  equipment  between 
central  nodes  and  functional  area  workstations  provides  the  following  capabilities; 

a.  Encryption  of  both  classified  and  unclassified  data  transmitted  to  and  from  a 
functional  area. 

b.  A  transmission  rate  of  9600  baud  and  greater,  using  either  asynchronous  or 
synchronous  equipments. 

c.  A  24  hour  a  day  dedicated  line  from  the  central  node  to  each  functional  area 
workstation. 

Q 

d.  Conditioning  to  a  bit  error  rate  of  1  in  10  . 


3. 1.4.2  Secondary  Intrasite  Communications.  Secondary  (backup)  communications 
equipment  provides  the  following  capabilities; 


a.  Encryption  of  data  transmitted  between  sites  and  classified  data  transmitted 
between  a  functional  area  and  its  central  node. 

b.  A  transmission  rate  of  300  baud  and  greater,  using  either  asynchronous  or 
synchronous  equipments. 

c.  Multiple  physical  paths  for  a  single  logical  path  (i.e.,  rerouting). 

d.  Availability,  as  required,  in  the  event  primary  communications  fail.  Over  a  given 
24-hour  period,  secondary  media  are  accessible  at  least  of  the  time. 


3. 1.4.3  Communications  Hardware. 


a.  Modems: 

(1)  Limited  Distance  Modenis.  Limited  distance  modems  are  required  tor 
on-base  use.  The  modems  must  be  capable  of  operating  over  available 
non-conditioned  voice  grade  telephone  lines  at  distances  of  at  least  e 
miles.  The  following  characteristics  are  required: 

(a)  Switchable  and  capable  of  transmitting  and  receiving  data  at  rates 
of  300,  600,  1200,  2400,  '-*^00,  and  9600  bits  per  second  (BPS)  up  to  e 
miles. 

(b)  The  limited  distance  modem  shall  meet  EIA  Standard 
ElA-RS-2 32-C/CCITT  Recommendation  V.24  for  interfacing  with 
external  equipment. 

(2)  Long  Distance  Modems.  Modems  used  outside  the  I  nited  States  (Europe, 
Asia)  on  non-conditioned  commercial  telephone  lines.  The  modem  is  a 
CODEX/V.29  data  modem  model  219h2  and  I’lust  be  hom.ologated  (PTT 
option)  to  the  country  where  the  svstem  is  installed.  The  v'v''DLV 
Universal  PTT  option.  Product  code  22120,  is  provided  when  required. 

b.  Line  Drivers.  Line  drivers  are  required  to  boost  the  electronic  si-tnul  tor 
communications  between  modems  and  CRTs  over  long  distances  (i.e.,  7  •>  teet  or 
more). 

c.  Encryption  Devices.  N'SA-endorsed  Data  Encryption  Standard  (DES)  devices  are 
required.  Functionality  may  be  combined  for  encryption  devices  and 
long/limited  distance  modems. 

3.1.3  Environmental  and  Physical  Facilities.  AFIRMS  equipment  must  operate  tliroughout 
the  ranges  of  electrical  power  and  environmental  tolerances  stated  below-. 

3. 1.3.1  Space. 


a.  Site  Locations.  The  system  is  located  at  the  Pentagon. 

b.  Flooring.  Equipment  shall  not  require  raised  flooring.  The  flooring  may  be 
carpeted.  There  will  be  no  special  static  control  facilities. 

c.  Ceiling  Height.  The  distance  from  the  floor  surface  to  the  unobstructed  ceiling 
is  at  least  S  feet. 


d.  Access  Route.  Equipment  is  installed  in  buildings  with  access  being  the  size  of 
a  normal  office  doorwary.  Additionally,  some  equipment  is  installed  in 
facilities  with  vault  doors,  raised  thresholds,  and  access  by  stairways.  Some 
facilities  are  established  computer  facilities  with  a  double  door  access  route. 
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3.J.j.2  EJectrlcaJ  Power.  All  equipments  must  be  capable  of  operating  within  the 
requirements  of  MIL-E-^158  and  are  further  defined  by  the  following: 


a.  Voltage  regulation  steady  state 

b.  Voltage  disturbances 
Momentary  undervoltage 
Transient  overvoltage 
Surges 

c.  Voltage  harmonic  distortion 

d.  Frequency  variation 

e.  Frequency  variation  rate  of  change 

f.  Power  factor 

g.  220/2^*0  Volts +or-10?6, 
single  phase,  2  wire. 

h.  1  1 0  Volts +or-l 0%,  single  phase, 

2  wire. 


+  10^  to  -15% 

30%  for  less  than  0.5  seconds 
-100%  acceptable  to  20  milliseconds 
200%  for  less  than  20  milliseconds 
lAVl  IEEE  587-1980 
+  3%  -5%  (with  linear  load) 

60Hz  plus  or  minus  IHz 
1  Hz/second 
0.8 


In  addition,  an  electrical  power  fault  detection  device  is  provided  to  prevent 
equipment  failure  (e.g.,  disk  head  crash). 


3. 1.5.3  Air  Conditioning.  The  ambient  temperature  will  be  maintained  by  the  U.S. 
Government  between  60  and  90  degrees  Fahrenheit  with  a  relative  humidity  of  between  20 
and  90  percent,  non-condensing.  No  special  dust,  static  electricity  control,  or  chilled 
water  facilities  are  available.  The  computer  is  integrated  with  the  air  conditioning 
system  to  provide  automatic  thermal  shutdown  to  prevent  equipment  failure  during 
extreme  high  or  low  temperature  conditions. 


3. 1.5.4  Remote  Locations.  Remote  equipment  is  installed  in  various  office  environments 
within  the  HQ  L'SAF.  Terminals,  office  printers,  and  modems  shall  fit  on  normal  table 
tops  or  desk  surfaces. 
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3. 1.5.3  TEMPEST  Requirement.  All  equipments,  connectors,  and  cabling  that  convey 
classified  information  must  meet  the  limits  specified  in  NACSIM  3100A.  All  equipment 
must  be  on  the  Preferred  Products  List  (PPL)  or  approved  by  AFCSC/EPV  San  Antonio, 
TX  7S243. 

3.2  Support  Software  Environment.  AFIRMS  software  is  broken  up  into  two  general 
categories:  Applications  Software  and  Support  Software.  Applications  Software  is  that 
software  which  applies  specified  algorithms  to  a  given  data  set,  and/or 
stores/retrieves/formats/analyzes/displays  a  given  set  of  data.  Applications  software 
programs/algorithms  are  enumerated  and  defined  in  the  AFIRVIS  Transforms  and  Models 
Document.  This  paragraph  describes  the  support  software  which  interfaces  with  the  HQ 
USAF  subsystem  applications  software  to  create  the  environment  necessary  to  support 
AFIRMS'  general  functionality  and  the  AFIRMS  Applications  Software. 

3.2.1  Central  Node  Support  Software.  Each  AFIRMS  Central  Node  requires  the  support 
software  identified  in  this  section. 


3.2. 1.1  Operating  System.  A  general  purpose  operating  system  provides  file  access, 
program  control,  and  data  communications  interfaces.  Operating  system  operation  (e.g., 
device  I/O)  must  not  significantly  impact  the  timing  and  flexibility  of  AFIRMS  operational 
software.  The  operating  system  must  be  able  to: 

a.  Concurrently  process  a  combination  of  interactive  and  local  batch  processing. 

b.  Support  a  multi-programming  environment. 

c.  Support  both  file  and  record  level  locking  protection  capabilities. 

d.  Provide  control  over  all  hardware  and  software. 

e.  Support  logical  as  well  as  physical  mode  access  to  all  system  peripheral  devices 
including  terminals. 

f.  Be  capable  of  detecting  and  marking  bad  blocks  while  formatting  system  and 
data  disks  as  well  as  during  normal  operation. 

g.  Support  up  to  8  concurrent  interactive  users  in  a  minimum  configuration  and  up 
to  20  concurrent  interactive  users  in  a  maximum  configuration. 


h.  Provide  access  to  a  calendar  clock  which  provides  the  calendar  aate  and  tirpe 
with  a  resolution  of  one  microsecond  (for  purposes  of  statistical  performance 
analysis  data  collection)  showing  hours,  miinutes,  and  seconds  for  time;  and  day, 
month,  and  year  for  date.  This  calendar  clock  is  accessible  to  all  programming 
languages. 

i.  Detect  and  terminate  attempts  to  read  or  write  outside  of  any  programs 
allocated  memory  and  detect  and  terminate  attempts  by  any  applications 
program  to  execute  privileged  and  undefined  instructions. 

j.  Provide  high  order  language  (HOL)  runtime  support  for  input/output  (I/O), 
scheduling,  and  interprocess  communication  and  coordination. 

k.  Provide  memory  fault  detection  and  recovery  capabilities. 

l.  Support  high  level  control  of  interrupt  detection,  definition,  and  processing 
activities. 

m.  Provide  the  capability  to  perform  dynamic  load  analysis  and  reporting. 

n.  Provide  host  language  interfaces  (system  directives)  to  system  functions. 

Utility  Routines.  The  following  utility  routines  are  required: 

File  Management  System 
Sort  and  Merge  Utility 

Translation  Utility  (character  code  conversion,  e.g.  ASCII  to  EBCDIC  and 
vice-versa) 

d.  Save  and  Restore  l/tility  (to  and  from  tape) 

e.  Security  Utility  (Error  surveillance  and  alerts;  to  recognize,  record  and  indicate 
misuse,  and  attempted  misuse,  of  the  system.) 

f.  Logging/Accounting  Utility  (An  automated  audit  trail  will  show:  access  made 
to  files;  how,  and  from  where  the  access  was  initiated;  the  identity  of  the 
person  or  process  that  initiated  the  access;  and  all  unauthorized  attempts.) 

g.  Diagnostic  Software 

h.  Mail  Utility 


3.2. 1.3  Communications  Software.  The  specific  requirements  for  comimunications 
software  are  determined  during  the  Analysis  Phase  that  precedes  implementation  at  each 
site.  However,  at  a  minimum,  a  host  interface  to  the  Defense  Data  Network  (DDN)  is 
recuirnd  for  each  AFIR.MS  site.  This  interface  implements  the  full  DDN  protocol  suite, 
and  supports  site-to-site  cornmunications  over  the  DDN.  It  also  provides  the  standard 


DPN  services  of  terminal-to-host  comnnunications,  file  transfer,  and  electronic  mail  to 
users  of  the  AFIRMS  system.  Connection  to  the  DDN  is  via  the  ARPANET  network 
access  protocols  or  X.25.  Host-to-host  communication  shall  be  via  the  Transmission 
Control  Protocol  (TCP),  MIL-STD  1778,  and  Internet  Protocol  (IP),  MIL-STD  .777.  The 
services  which  are  supported  are  TELNET,  File  Transfer  Protocol  (FTP),  and  the  Simple 
Mail  Transfer  Protocol  (SMTP). 

Encryption  services  provided  by  the  DDN  are  limited  to  SECRET  security 
classifications.  However,  with  user  acquisition  of  TOP  SECRET  security  classification 
encryption  devices,  the  DDN  can  be  accessed  for  transmission  of  TOP  SECRET 
information. 

3.2. 1.4  Database  Management  System  (DBMS).  The  AFIRMS  DBMS  performs  the  action 
of  retrieving  a  record  from  a  file,  writing  a  record  to  a  file,  and  deleting  and  creating 
records  in  a  file.  The  DBMS  also  performs  functions  such  as  opening  and  closing  the 
database,  transaction  flow,  handling  of  the  DBMS  command  language  requests,  transaction 
parsing,  and  automatic  editing  on  input.  In  addition,  the  DBMS  allows  for  host  language 
interfaces;  save  and  restoration  of  full  or  partial  database  images;  restart  and  recovery 
capability  with  multi-user  and  multi-thread  concurrency  controls;  and  some  level  of 
distributed  or  decentralized  data  management  with  the  appropriate  synchronization  and 
concurrency  controls.  The  specific  level  of  data  synchronization  control  and  data 
distribution  or  decentralization  required  is  determined  during  the  Analysis  Phase  that 
precedes  implementation  of  each  functional  block  at  HQ  L’SAF. 

For  a  detailed  statement  of  required  AFIRMS  DBMS  capabilities,  refer  to  the 
AFIRMS  HQ  L'SAF  Database  Specification. 

In  addition  to  the  software  that  comprises  the  AFIRMS  DBMS,  a  software  package 
provides  a  shell  to  the  DBMS  which  accomplishes  the  following: 

a.  Controls  entry  to  and  exit  from  DBMS  functions. 

b.  Provides  a  link  or  connection  between  the  communications  software  ana  the 
DBMS. 

c.  Controls  data  retrieval  and  data  update  transactions. 

d.  Generates  a  queue  for  transactions  by  transaction  priority. 


e. 


Performs  update  notifications  to  other  sites  for  data  changes  (deletions, 
additions  or  modifications)  in  a  DBMS  file. 


f.  Determines  whether  data  retrieval  and  update  transactions  are  to  be  routed  to 
the  local  (functional  area)  database  or  the  central  database. 

g.  Provides  a  link  between  parameter  screen  software  and  the  DBMS  in  order  to 
verify  the  validity  of  parameter  selections. 


3.2.2  Functional  Area  Support  Software.  Each  AFIR.MS  functional  area  requires  the 
support  software  specified  in  this  section. 


3.2.2. 1  Operating  System.  Functional  Area  operating  system  capabilities  are  identical  to 
those  of  the  Central  Node  Module,  identified  in  Section  3.2. 1.1  of  this  subsystem 
specification.  Ho\\ever,  the  following  exception  applies: 


a.  The  FA  operating  system  must  support  at  least  1  interactive  user  in  a  minimium 
configuration  and  up  to  3  concurrent  interactive  users  in  a  maximum 
configuration. 


3. 2. 2. 2  Utility  Routines.  FA  utility  routine  requirements  are  the  same  as  those  of  the 
CNM,  identified  in  Section  3.2. 1.2  of  this  subsystem  specification. 


3. 2. 2. 3  Communications  Software.  The  specific  requirements  for  comimunications 
software  are  determined  during  the  Analysis  Phase  that  precedes  implementation  at  each 
site.  Communications  between  the  CNM  and  the  intelligent  FA  terminals  is 
accommodated  by  con- munications  protocol(s)  identified  or  confirmed  during  the  Analysis 
Phase  of  each  functional  block  implementation.  The  volume  and  freauenc>  of  the  various 
information  gateways  by  functional  area  is  presented  in  the  AFIRMS  HO  LSAF  Database 
‘specification  and  Section  ^.3.2  of  this  subsystem  specification. 


3. 2. 2. 4  Database  Management  System  (DBMS).  Functional  Area  DBMb  and  DBMS  support 
canabilities  are  identical  to  those  of  the  Central  Node  Module,  identified  in  Section 
3.2.2. 1  of  this  siibsysten'  specif ication. 
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3,2,2. 5  Display/Graphics  Software.  AFIRWS  display  screens  are  categorized  by  their 
method  of  display;  graphic,  tabular,  integrated  graphic  and  tabular.  The  tabular  screens 
display  the  data  values  listed  in  table  format,  i.e.,  rows  and  columns.  The  tabular  screens 
may  use  color  to  identify  data  of  like  types  to  help  the  user  assimilate  the  information. 
The  tabular  screens  also  use  colors  to  highlight  a  line  and/or  field  as  a  screen  place 
marker  for  the  user,  or  to  call  attention  to  changes  in  data  currency. 

The  graphic  screens  are  of  three  types:  bar  graph,  line  graph,  and  pictoral  (i.e., 
maps).  These  are  output  screens  only  (i.e.,  they  cannot  be  updated  through  the  display 
screen).  In  addition,  the  bar  graph  screens  have  a  data  value  atop  each  graphed  bar  that 
quantifies  the  analog  display. 


The  display  screen  generation  software  uses  standard  routines  to  generate  these 
screens.  In  summary,  the  generalized  routines  and  particular  features  are: 

a.  Tabular  Screen  Generator  must  possess  the  following  characteristics: 

(1)  Right-justified  numeric  data. 

(2)  Left-justified  alphanumeric  data. 

(3)  Line  highlighter  that  can  be  turned  (i.e.,  toggled)  on  or  off. 

(L)  Field  highlighter  that  can  be  turned  (i.e.,  toggled)  on  or  off. 

(3)  Full  screen  editor  (for  extensive  data  input  and  editing  capability) 

(6)  Linkable  to  a  special  area  on  the  screen  to  display  remarks  for  a  row  of 
data  (e.g..  Unit  and  Base  Status  products).  This  requires  that  the  display 
routine  know  where  the  cursor  is  by  page  and  by  row  in  order  to  call  up 
the  correct  set  of  remarks/data. 

(7)  Variable  legend,  either  data-driven  or  user-defined. 

(S)  Blanking  of  repeating  column  data  (selectable). 

(9)  Capability  to  identify  (e.g.,  via  blinking,  changed  color,  etc.)  a  row  or 
column  of  data  that  has  changed  from  an  original  or  previous  data  set. 
The  means  by  which  this  "data  change  indicator"  is  activated  is 
determined  during  the  Analysis  Phase  that  precedes  implementation  of 
particular  functions  which  require  this  capability. 

( 1 0)  Field  and  row  coloring  depending  on  value  of  data  field  (selectable). 

(11)  Column  headings  programmable  separately  from  bodv  of  table. 
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(12)  \on-sequential  vertical  paging  (up/reverse,  down/forward)  as  well  as 
horizontal  paging  and/or  segmentation  (i.e.,  virtual  screen)  capability. 


b. 
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(1  3)  Scrolling  (up,  down,  left,  right)  to  augment  the  paging  feature. 

(14)  Capability  to  generate  a  hard  copy  from  a  screen  display  without  using  a 

system  printer. 

(1  5)  Data  error  checking  and  validation  capabilities  to  include  checking  of 

input  data  for  legal  values,  length  and  format,  as  well  as  upper  and  lower 

case  and  special  character  recognition. 

(16)  Grid  generation  capability. 

(17)  Title,  subtitle,  and  heading  generation  capability. 

(18)  Horizontal/vertical  field  count/sum  feature. 

The  Graphic  Screen  Generator  must  possess  the  following  characteristics; 

(1)  Line  Graph  and  Bar  Graph  Generators  share  some  common  capabilities: 

(a)  Variable  legends,  either  data-driven  or  user-defined. 

(b)  Automatic  x-  and  y-axis  scaling. 

(c)  Y-axis  rescaling  after  screen  display  initiated  by  a  function  key. 

(d)  Capability  to  identify  (e.g.,  via  blinking,  changed  color,  etc.)  data 
that  has  changed  from  an  original  or  previous  data  set.  The  means 
by  which  this  "data  change  indicator"  is  activated  is  determined 
during  the  Analysis  Phase  that  precedes  each  functional  block 
implementation. 

(e)  Field  coloring  depending  on  value  of  data  field  (selectable). 

(f)  Capability  to  generate  a  hard  copy  from  a  screen  display. 

(2)  Map  Maker  capabilities: 

(a)  Linkable  to  a  special  area  on  the  screen  to  display  remarks  or  other 
data  relevant  to  the  display.  This  requires  the  routine  to  know 
where  the  cursor  is  on  the  display  in  order  to  call  up  the  correct 
information. 

(b)  A  coordinate  system  so  Air  Bases  or  other  items  of  interest  can  be 
inserted,  labeled  and  deleted  by  a  nontechnical  user  using  latitude 
and  longitude  or  Geographic  F^eference  (GEOREF)  map  coordinates 
(the  positioning  wRi  be  reasonably  accurate  with  relation  to  one 
another). 

(c)  Coloring  of  the  base  position  according  to  the  dynamic  values  of  a 
set  of  database  variables  (the  color  indicates  a  condition  or  status). 


3-16 


(d)  A  change  indicator  for  positions  whose  status  or  condition  values 
were  changed. 

(e)  Continuously  variable  software  zoom  (if  not  a  hardware  capability). 

(f)  The  capability  to  generate  and  display  special  symbols. 

(g)  Capability  to  generate  a  hard  copy  from  a  screen  display. 

Display  Screen  Parameter  Software  must  possess  the  following  characteristics: 

(1)  The  parameter  software  interacts  with  the  AFIRMS  database  when 
necessary,  to  determine,  generate,  and  list  the  appropriate  parameter 
choices  for  the  database  set  requested.  For  example,  if  ATO  3  (the 
specified  database  set)  does  not  have  CBU-52  munitions  (a  parameter 
selection)  tasked,  then  the  list  of  choices  for  a  munition  type  (the 
parameter)  will  not  include  CBU-52. 

(2)  The  parameter  software  is  interpretive  in  nature  so  as  to: 

(a)  Ensure  a  consistent  and  well-defined  interface  to  the  database 
transaction  software. 

(b)  Provide  a  flexible  and  user-friendly  mechanism  for  user  selection  of 
alternative  data  sets. 

(c)  Allow  the  user  to  enter  synonymous  parameter  selections;  e.g. 
"YES",  "YE",  "Y",  "OK"  can  all  be  entered  (and  subsequently 
interpreted  by  the  system)  as  an  affirmative,  instead  of  forcing  the 
user  to  precisely  reflect  database  values. 

(3)  The  parameter  software  also  permits  write-in  choices  where  appropriate. 
In  some  instances  it  is  not  possible  or  practical  to  list  all  appropriate 
parameter  selections. 

Function  Keys.  AFIRMS  is  operated  utilizing  a  system  of  menus  and  special 
function  keys.  Some  of  the  product  screen  function  keys  can  be  seen  at  the 
bottom  of  the  display  screens  described  in  the  AFIRMS  Product  Description 
annexes.  As  the  number  of  available  function  keys  is  less  than  the  number  of 
required  keys,  arrays  of  keys  are  utilized  to  overcome  that  problem. 

The  first  array  contains  the  basic  key  functions  needed  for  every  display  screen. 
Except  for  the  Base  Status  Map,  the  graphic  displays  require  only  the  first 
array.  The  tabular  input  screens  require  key  functions  to  add,  delete,  and 
change/edit  data.  A  paging  and/or  scrolling  capability  is  required.  Some  records 
have  sub-records  (e.g.,  a  wing  with  several  munitions  as  in  the  Wing  Resource 
Summary  Product,  a  mission  with  two  aircraft  Mission  Design  Series  and/or 
aircraft  Standard  Conventional  Loads  as  in  the  Tasking  Information  products). 
Therefore,  the  second  array  is  reserved  for  editing  records,  and  the  third  array  is 
reserved  for  editing  sub-records.  Switching  between  arrays  is  done  with  two 
special  function  keys.  An  arrow  on  either  or  both  ends  of  the  function  key  array 
shows  the  user  which  array  is  in  use.  The  required  functions  of  these  function 
kevs  are  outlined  in  Table  3-1. 


Table  3-1 

PRODUCT  DISPLAY  SCREEN  FUNCTION  KEY  DESCRIPTION 


Key  Label 
1st  Array: 


Function  Description 


DISPLAY 
PAR  AM 
SELECT 


Takes  the  user  back  to  the  parameter  selection  screen.  The  parameter 
choices  the  user  made  to  display  the  product  are  redisplayed. 


LINE 

HIGHLIGHT 

TOGGLE 


Changes  the  state  of  the  Line  Highlighter  toggle.  If  it  is  turned /toggled  OFF, 
the  state  is  changed  to  ON  and  the  Line  Highlighter  appears.  If  it  is  toggled 
ON,  the  state  is  changed  to  OFF  and  the  Line  Highlighter  is  removed  from  the 
tabular  display.  The  function  key  is  not  active  when  a  graphic  screen  is  displayea. 


HARD 

COPY 


TOP 

MENU 


Spawns  a  batch  process  to  print  a  color  copy  of  the  display.  This  key  is 

on  the  1st  array  only  if  the  product  has  a  single  screen  display.  For  multiscreen 

displays,  the  key  is  on  the  2nd  array  with  the  paging  keys. 

Returns  the  user  to  the  first/top  menu. 


PREVIOUS 

MENU 


Returns  the  user  to  the  menu  from  which  the  product  was  selected. 


HELP 


Interrupts  the  product  display  and  takes  the  user  to  the  HELP  system.  hen 
finished  with  the  HELP  screen,  the  user  returns  to  this  display. 


UPDATE 

SCREEN 


Causes  the  system  to  refresh  or  update  the  product  display  using  the 
current  parameter  choices.  Normally  used  with  a  resource  status  product  when 
the  system  notifies  the  user  that  the  status  data  has  been  updated. 


2nd  Array: 


PAGE 

REVERSE 


Page  the  product  in  reverse  order.  It  pages  a  full  or  half  page  at  a  time, 
depending  on  the  paging  option  selected.  It  is  active  only  when  a  tabular  product 
IS  displayed  and  is  longer  than  one  page  of  display. 


FULL  PG 
HALF  PG 


Changes  the  paging  state  to  FULL  or  HALF  paging,  depending  on  the 
current  state.  The  current  paging  state  is  always  highlighted  or  colored. 


PAGE 

FORWARD 


Causes  the  system  to  page  the  product  forward  in  sequential  order.  It 

pages  a  full  or  half  page  at  a  time,  depending  on  the  paging  option  selected.  It  is 

active  only  as  described  in  PAGE  REVERSE  above. 


CHANGE 

XXXXXX 

DATA 


Permits  editing  of  the  screen  data.  The  'XXXXXX'  is  changed  to  the 
appropriate  term  (such  as  aircraft  or  aircrew)  when  the  product  is 
designed.  Used  only  for  tabular  products.  Pressing  the  function  key  a  second 
time  de-activates  the  CHANGE  mode. 


ADD 

XXXXXX 

DATA 


Permits  the  addition  of  a  record  to  the  database.  L  sed  only  for  tabular 
products.  Pressing  the  function  key  a  second  tim.e  de-activates  the 
ADD  mode. 


J 
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Table  3-1 


PRODUCT  DISPLAY  SCREEN  FUNCTION  KEY  DESCRIPTION  (Continued) 


Key  Label 

Function  Description 

DELETE 

XXXXXX 

DATA 

Permits  the  deletion  of  a  record  from  the  database.  Used  only  for  tabular 
products.  Pressing  the  function  key  a  second  time  de-activates  the 
DELETE  mode. 

ENTER 

Updates  the  data  base  as  directed  by  the  three  previous  keys  keys 
(CHANGE,  ADD,  and  DELETE  XXXXXX  DATA).  The  ENTER  key  acts  as 
a  confirmation  step  for  the  CHANGE/ADD/DELETE  keys. 

INTERROGATE 

BASE 

Interrogates  the  cursor  position  and  displays  a  box  containing  data  corres¬ 
ponding  to  the  base  displayed  under  the  cursor  (see  Base  Status  Map). 

DELETE 

DATA  BOX 

Deletes  the  box  containing  the  base  data. 

SCALE  UP 

Increases  the  y-axis  scale  of  the  bar  graph  by  approximately  ICG':’^  after 
the  screen  is  displayed.  Used  with  bar  graphs  only. 

SCALE  DO\fcN 

Decreases  the  y-axis  scale  of  the  bar  graph  by  approximately  509o  after 
the  screen  is  displayed.  Used  wfith  bar  graphs  only. 

3rd  Array: 

PAGE 

REVERSE 

Page  the  product  in  reverse  order.  It  pages  a  full  or  half  page  at  a  tinie, 
depending  on  the  paging  option  selected.  It  is  active  only  when  a  tabular 
product  is  displayed  and  is  longer  than  one  page  of  display. 

FULL  PG 

HALF  PG 

Changes  the  paging  state  to  FULL  or  HALF  paging,  depending  on  the 
current  state.  The  current  paging  state  is  always  highlighted  or  colored. 

PAGE 

FORWARD 

Causes  the  system  to  page  the  product  forward  in  sequential  order.  It 
pages  a  full  or  half  page  at  a  time,  depending  on  the  paging  option 
selected.  It  is  active  only  as  described  in  PAGE  REVERSE  above. 

CHANGE 

XXXXXX 

DATA 

Same  as  CHANGE  XXXXXX  DATA  key  above  except  only  sub-record  data 
is  changed.  The  system  prevents  changes  to  record  keys/data. 

ADD 

XXXXXX 

DATA 

Same  as  ADD  XXXXXX  DATA  key  above  except  able  to  add  sub-recoras 
only. 

DELETE 

XXXXXX 

DATA 

Same  as  DELETE  XXXXXX  Da\TA  key  above  except  able  to  delete 
sub-records  only. 

ENTER 

Lpdates  the  data  base  as  directed  by  the  three  previous  keys 
(CHANGE,  ADD,  and  DELETE  XXXXXX  DATA).  The  ENTER  key  acts  as 
a  confirniation  step  for  the  CHANGE/ADD/DELETE  keys. 

3.2. 2. 6  User  Interface  Software.  The  prunary  functions  of  this  software  subsystem  are  as 
follows: 

a.  It  provides  the  AFIR.MS  user's  sole  view  of  the  AFIR.VIS  system. 

b.  It  serves  as  the  link  by  which  the  AFIRMS  user's  requests  are  translated  into 
internally  recognized  system  functions,  validated,  and  subsequently  performed  by 
the  system. 

The  software  providing  user  interface  to  the  AFIRMS  system  possesses  the  following 
characteristics: 

a.  Menu  driven  with  a  command  language  available  to  provide  software  capabilities 
for  experienced  users. 

b.  Consistent  menu  displays  and  underlying  definitions. 

c.  L'ser-friendly. 

d.  Fault-tolerant. 

e.  Menu  paging  or  scrolling. 

f.  Help  available  at  all  levels  of  user/system  interaction. 

g.  Allows  for  multiple  access  paths  to  all  user  functions  (via  functional  area 
workstation  groupings,  alphabetical  lists,  logically  related  system  functions,  etc.) 

h.  Provides  functionality  to  accept  specified  user  parameters  which  limit 
information  returned  for  screen  data  retrieval  requests. 

i.  Provides  functionality  to  allow  interactive  "through  the  display  screen"  updates  to 
the  AFIRMS  database  (as  discussed  in  section  3.2.2. 5  of  this  subsystem 
specification), 

j.  Detects  and  automatically  logs  off  terminals  which  have  been  inactive  for  an 
operator  definable  period  of  time.  This  time  is  determined  and  set  by  the  system 
operator. 

3.3  Interfaces.  AFIRMS  avoids  data  redundancy  where  possible;  however,  some 
redundancy  is  required  for  deployment  and  response  time  requirements.  AFIRMS,  where 
possible,  also  maximizes  the  use  of  IjSAF  (and  other  suitable  DoO  Automated  Data 
Processing  Systems  (ADPSs))  to  provide  AFIRMS  information.  Interfaces  to  external  (e.g., 
I  SAF,  DoD)  automated  systems  are  discussed  in  the  AFIRMS  System  Specification. 

The  HO  I  SAF  subsystem  interfaces  with  wing  and  M  A3COM  subsystems  through 
cofnputer-to-computer  network  software  products.  These  products  link  various  operating 
systerns  and  provide  the  functionality  required  to  effect  inforrnation  flows  between 
AFIRMS  subsvstems. 
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As  AFIRMS  intends  to  host  on  existing  hardware  and  equipments  as  much  as  possible, 
the  specific  protocols  to  be  used  are  largely  dependent  upon  existing  and/or  planned  Air 
Force  ADPSs.  Thus,  they  are  determined  or  confirmed  during  the  Analysis  Phase  that 
precedes  implementation  of  each  functional  block. 

AFIRMS  is  developed  to  take  advantage  of  currently  existing  systems  that  already 
provide  accurate  data  collection.  It  is  also  designed  to  take  advantage  of  systems  that 
produce  capability  assessments  using  a  subset  of  the  resources  AFIRMS  ultimately  uses  to 
produce  its  capability  assessments.  In  order  to  handle  interfaces  with  future  developing 
systems,  AFIRMS  is  designed  modularly  with  generic  data  gateway  interfaces.  As  these 
new  systems  are  implemented,  they  can  easily  be  interfaced  with  AFIRMS.  These  generic 
interfaces  apply  to  communications  networks  as  well  as  data  systems. 

AFIRMS  is  data  collection  intensive.  However,  AFIRMS  attempts  to  minimize 
duplication  of  the  collection  of  any  data  that  is  already  being  collected  by  another  system 
(e.g.,  munitions  data  collected  by  Combat  Ammunition  System  (CAS)).  In  addition, 
AFIRMS  does  not  compute  an  assessment  that  is  already  suitably  available  in  another 
system  (e.g.,  spares  analysis  computed  by  Weapon  System  Management  Information 
System  or  WSMIS). 


3.3.1  AFIRMS  Intrasite  Interfaces.  The  transactions  that  occur  within  a  particular 
AFIRMS  site  require  three  types  of  interface  specifications: 


a.  Intrasite  Transaction  Header.  This  interface  specification  defines  the  format 
of  the  information  required  to  transmit  any  transaction  to/from  the  CNM  from 
any  functional  area  workstation. 

Appendix  A  provides  the  detailed  specification  of  the  information  contained  in 
this  header  interface. 

b.  Display  Screen  Interfaces.  These  interface  specifications  define  the  format  of 
the  data  that  is  retrieved  on  behalf  of  the  functional  user  in  accordance  with 
his/her  input  parameters  and  subsequently  transmitted  to  the  functional  area. 
Each  of  these  interface  specifications  also  requires  an  Intrasite  Transaction 
Header  as  defined  above. 


Table  3-2  provides  a  cross-reference  between  the  AFIRMS  output  reports  set 
forth  in  Section  4.3.2  of  this  subsystem  specification  and  the  AFIRMS  internal 
interface  specifications  provided  in  Appendix  D. 
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Table  3-2 

APIRMS  OUTPUT  REPORT 
(CROSS-REFERENCE  TO  APPENDIX  B) 


Screen  Title 

Interface 

Spec.  Appendix 
Cross-Reference 

Aircraft  &  Mission  Tasking  Details 

APIB/S 

Aircraft  Spares  Support  Capability 

APIB/S 

Aircraft  Tasking 

B-2 

Attrition  Trends 

APIB/S 

Base  Fuels  Capability 

B-2 

Base  Status  (Input) 

B-1 

Base  Status  (Output) 

B~1 

Capability  Perspective 

B-2 

Communications  Support  Status 

APIB/S 

Dollars  to  Readiness  -  Comparisons  (All  Resources) 

B-6 

Dollars  to  Readiness  -  Comparisons  (Fuels) 

’  B-6 

Dollars  to  Readiness  -  Resource  Perspective 

B-6 

Fuels  Capability 

B-2 

Individual  Resource  Capability 

B-2 

Integrated  Capability 

B-2 

Mission  Area  Tasking 

APIB/S 

Mission  Profile  Definition 

B-1 

Mission  Tasking 

APIB/S 

Munitions  Capability 

B-2 

Munitions  Status 

B-1 

Munitions  Substitution  Sortie  Capability 

APIB/S 

Munitions  Substitution  Sortie  Requirement 

APIB/S 

OPlan/OPORD  Associations 

B-1 

Order  Assignments 

B-1 

Process  Status 

B-1 

Resource  Reallocation 

B-1 

Resource  Unit  Price 

B-1 

Status  Map 

B-3 

Unit  Status  (Input) 

B-1 

Unit  Status  (Output) 

B-1 

Var  Mobilization  Plan 

B-1 

Ving  Flying  Day 

B-1 

Wing  Operations  Rates 

B-1 

Wing  Resource  Summary 

B-1 

Wing  Resupply  Schedule 

B-1 

*APIB/S  -  Analysis  Phase  Initial  Block  for  each  Segment 
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c.  Data  Update  and  Retrieval  Transaction  Interfaces. 

The  logical  data  flow  for  data  update  and  retrieval  transactions  is  provided  in 
Tables  3-3  and  3-4  respectively. 

Tables  3-5  and  3-6  provide  the  interface  specifications  for  the  data  update  and 
data  retrieval  requests,  respectively.  Each  of  these  requests  also  requires  an 
Intrasite  Transaction  header  as  defined  above. 


3.4  Security.  The  HQ  USAF  operational  AFIRMS  ADPS  processes  data  up  to  a 
classification  level  of  TOP  SECRET,  and  HQ  USAF  personnel  have  clearances  and 
need-to-know  at  the  highest  classification  level  of  data  being  processed  or  stored  in  the 
facility.  Although  sites  at  the  wing  level  operate  in  the  Controlled  Security  Mode,  HQ 
USAFE  (MAJCOM  Headquarters)  and  the  HQ  USAF  sites  operate  in  the  System  High 
Security  Mode.  This  is  accomplished  by  utilizing  a  combination  of  the  following  security 
measures: 


a.  Personnel  Security.  All  personnel  having  access  to  MAJCOM  and  HQ  USAF 
AFIRMS  facilities  and/or  data  have  a  security  clearance  equal  to  the  highest  level 
of  classification  being  processed,  stored  or  displayed.  At  all  AFIRMS  sites,  each 
user's  identity  is  positively  established  via  user  IDs  and  logon  passwords  (terminal 
display  of  which  are  suppressed),  which  are  used  to  authenticate/verify  AFIRMS 
users'  identities  and  their  corresponding  access  privileges.  AFIRMS  provides  a 
capability  to  prevent  unauthorized  users  from  executing  a  protected  program  or 
series  of  programs. 

A  personnel  security  program  is  implemented  for  the  AFIRMS  program  in 
accordance  with  the  provisions  of  DoD  Regulation  5200.2/AFR  205-32  USAF 
Personnel  Security  Program.  Personnel  access  controls  are  implem.ented  for  the 
AFIRMS  central  computer  facilities  and  remote  terminal  areas. 

(1)  Central  Computer  Facility.  Strict  personnel  access  controls  must  be 
implemented  to  ensure  that  the  only  personnel  admitted  are  those  who 
require  access  to  the  central  computer  facility,  and  possess  a  security 
clearance  at  least  equal  the  highest  classification  of  information  being 
processed  or  openly  stored  at  the  facility. 

(2)  Remote  Terminal  Area(s).  Authorization  for  access  to  and  the  use  of  remote 
terminal  devices  is  based  on  an  individual's  duties,  his/her  need  to  use  the 
terminal,  and  possession  of  a  security  clearance  of  the  required  level. 

b.  Physical  Security.  Measures  must  be  taken  to  ensure  external  protection  for 
AFIRMS  against  unauthorized  access  to  the  central  computer  facility,  to  the 
system  from  remote  terminals,  and  to  data  storage  media. 


(1) 


Central  Computer  Facility.  Central  computer  facility  physical  security  o  ust 
meet  the  requirements  established  for  the  highest  classification  and  all 
sensitivity  categories  of  data  that  are  either  resident  in  the  ADPS  or  openly 


stored. 
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TABLE  3- 3a 


DESCRIPTION  OF  DATA  FLOW 
FOR 

DATA  RETRIEVAL  TRANSACTIONS 
(Functional  Area  Workstation) 


User  logs  onto  FAVl  by  entering  username  and  password. 

If  username/password  combination  is  invalid,  then 

The  FA'A  keeps  track  of  the  number  of  consecutive  times  this  occurs,  as  well  as  the 
invalid  information. 

If  invalid  information  has  been  entered  three  times  in  a  row,  then 

FAW'  logically  locks  the  terminal  from  further  use  by  saving  the  information  on 
the  disk  and  indicating  that  state. 

FAVt  generates  a  siren-like  sound  indicating  the  security  violation. 

FAW  displays  the  security  violation  screen. 

FAW  sends  to  the  ACNM  (if  possible)  a  security  message  indicating  the  problem. 
The  ACWl  notifies  the  security  officer  via  three  wavs: 

(1)  bends  a  message  directly  to  his/her  terminal  il  he/she  is  logged  on. 

(2)  Sends  a  security  message  to  his/her  mailbox. 

(3)  Sends  the  securitv  message  to  the  sv stern  manager’s  hardcopy  device. 

Else 

FAW  gives  user  another  chance  to  logon  properly. 

Endif 

Else  [valid  user  logon  has  occurred  on  the  FAVl  ] 

FAW  attempts  to  logon  to  the  ACNM  by  passing  the  usernainc/password  entered. 

The  ACWl  performs  security  checks. 

If  a  security  violation  has  been  detected,  then 

Av'Wl  logically  locks  the  terminal  port  from  further  use  by  saving  information 
on 

the  disk  and  indicating  that  state. 

The  Av'Wl  notifies  the  security  officer  via  three  ^vavs: 

(1)  Senas  a  message  directly  to  his/her  terminal  if  ne/she  is  logged  on. 

(2)  Sends  a  security  message  to  his/her  mailbox. 

(3)  Sends  the  security  message  to  the  system  manager's  hardi'opy  device. 

The  ACWl  tells  the  FAW  of  the  security  violation. 

Lise  [  valid  user  logon  lias  occurred  on  tfie  Av'Wl  | 

AFIKMS  processes  are  started  tlvat  run  on  the  user's  Seiialt. 

It  there  is  no  proble'".  starting  ttiese  processes,  then 

AFIK’MS  '-ode  and  data  needed  lor  the  user  are  downloafied. 

If  -ill  r'e<  essarv  'fata  vicci  c  ode  reacfi  tfie  I  \  V\  suci'ess  f  ul  1  v  .  tfien 

Tf-ie  \v  \\1  g(*rs  ready  ter  reuuests  IrvMn  the  1  \W  on  betiaif  of  tlie 

Tfie  ly'Wl  tells  ttie  F\W  ttiat  fa'  t. 

1 . 1  V' 

l  uere  IS  a  protilem. 

imdi  1 

Fiidit 


TABLE  3- 3a 


DESCRIPTION  OF  DATA  FLOW 
FOR 

DATA  RETRIEVAL  TRANSACTIONS 
(Functional  Area  Workstation)  (Continued) 


If  there  is  a  problem  on  the  ACNM,  then 

The  ACMN  informs  the  FAW  of  the  problem. 

The  ACNM  logs  the  user  off  AFIRMS. 

The  FAVl  notifies  the  user  of  the  problem. 

If  a  local  database  for  this  user  exists  from  a  previous  logon,  then 

the  user  is  allowed  to  make  requests  of  his/her  local  database  only. 
Else 

The  FAW  notifies  the  user  of  the  problem. 

The  FAW  logs  the  user  off  AFIRMS. 

Endif 

Endif 

Endif 

Endif 

[CNM  checks  for  data  stored  on  behalf  of  the  user  on  non-volatile  random 
access  medium.] 

If  ACNM  finds  data  destined  for  the  user,  then 
ACNM  sends  FAW'  user  data  summary. 

Endif 

ACNM  sends  FAW  the  currently  available  CPU/processing  power  for  each  CNM. 
FAW  notifies  user  of  data  stored  on  his/her  behalf  le.g.,  previous  request,  mail). 

If  user  chooses  details  of  his/her  CNM  data,  then 
FAW  displays  user  data  summary. 

[User  selects  which  data  he/she  wishes  to  view/delete.] 

Endif 

If  user  wishes  to  view/delete  a  dataset,  then 

If  ACNM  can  be  talked  to  via  normal  communications  link  or  dial-up,  then 
The  view/delete  request  is  transmitted  to  the  ACNM. 

Else 

The  user  is  notified  that  there  is  a  problem. 

The  user  is  asked  to  make  another  request. 

Endif 

Endif 


TABLE  3-3a 


DESCRIPTION  OF  DATA  FLOW 
FOR 

DATA  RETRIEVAL  TRANSACTIONS 
(Functional  Area  Workstation)  (Continued) 


F -WV  user  requests  screen  for  viewing  via  FAW  MMI. 

[FAW  database  is  checked  for  required  data.] 

If  all  data  exists  (is  resident)  locally,  then 

FAVt  software  determines  if  the  response  time  would  be  faster  by  allowing  a  CNM  to 
perform  the  request. 

If  processing  is  faster  on  the  CNM,  then 
The  request  is  transmitted  to  the  ACNM. 

Else  [processing  is  faster  locally] 

The  FAW  handles  the  request  locally. 

Endif 

Else  [some  or  all  of  the  data  exists  elsewhere] 

The  user  is  informed  that  his/her  request  requires  access  to  the  CNM's  database. 

The  user  is  asked  for  confirmation  of  the  request. 

If  the  user  confirms  the  request,  then 

If  the  ACNM  can  be  talked  to  via  normal  link  or  dial-up,  then 
The  request  is  transmitted  to  the  ACNM. 

Else 

The  user  is  notified  there  is  a  problem. 

The  user  is  requested  to  make  another  screen  selection. 

Endif 

Else  [the  user  didn't  confirm  the  request] 

The  user  is  requested  to  make  another  screen  selection. 

Endif 

Endif 


Acronym  Definitions 


ACNM 

AFAW 

CNM 

FAW 

M  MI 

NCNM 

NFAW 

OCNM 
OF  AW 
PCNM 


-  the  CNM  directly  attached  to  the  user's  FAW 

-  all  functional  area  workstations  attached  to  an  ACNM 

-  central  node  module/manager 

-  functional  area  workstation 

-  man-machine  interface 

-  CNM  that  the  user  is  newly  attached  to  (assuming  he  logged  off  while  his 

request  was  being  processed) 

-  newly  logged-onto  FAW 

-  original  CNM  that  received  a  FAW  request 

-  original  FAW  that  made  a  request 
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TABLE  3-3b 


DESCRIPTION  OF  DATA  FLOW 
FOR 

DATA  RETRIEVAL  TRANSACTIONS 
(Central  Node  Manager) 


The  ACNM  receives  a  FA\X  request  for  data  retrieval. 

[The  OCN.M  determines  which  CNM  can  best  process  the  request,] 

If  the  request  should  be  handled  by  a  "different"  CNM,  then 

The  request  is  transmitted  to  the  CNM  that  can  best  handle  it. 

Endif 

If  there  are  requests  currently  queued,  then 

[  A  separate  queue  is  maintained  for  updates.  It  is  always  serviced  before  the  query  queue 
in  order  to  minimize  database  conflicts.] 

The  request  is  queued  according  to  priority  using  a  FIFO  algorithm. 

As  requests  are  completed,  the  next  request  performed  is  the  one  at  the  top  of  the 
highest  priority  queue  with  a  request  currently  queued. 

Else  [there  are  no  other  reauests  queued] 

The  request  is  perfonned  immediately. 

The  PCNM  transmits  to  each  AFAVt  and  all  other  CNMs  its  currently  available 
(unused)  CPL/processing  power. 

Endif 

The  CNM  that  processes  the  request  transmits  to  each  attached  FA  and  all  other  CNMs 
its  currently  available  processing  power.  Each  of  the  "other"  CNMs  also  transmits  this 
processing  capability  to  its  FAWs. 

[VI  hen  an  interactive  request  is  completed,  the  results  are  sent  back  to  the  requesting 
user.] 

If  tlie  request  was  handled  by  other  than  the  OCNM,  then 

[First  a  check  is  made  to  see  if  the  user  is  still  logged  onto  anv  of  the 
OCNM's  FAW  s.] 

If  the  PCNM  can  talk  to  the  OCNM,  then 

The  PCNM  sends  a  "check  if  the  user  is  still  logged  on"  request  to  the  OCNM. 

The  OCNM  sends  a  response  to  the  PCNM. 

If  the  user  is  still  logged  onto  the  OCNM,  then 
The  PCNM  transmits  the  results  to  the  OCNM. 

Elseif  the  user  is  logged  onto  any  of  the  PCNM's  FAWs,  then 
The  PCNM  transmits  the  results  to  the  user's  NFAW. 


TABLE  3-3b 


DESCRIPTION  OF  DATA  FLOW 
FOR 

DATA  RETRIEVAL  TRANSACTIONS 
(Central  Node  Manager)  (Continued) 


Elseif  the  PCNM  can  talk  to  the  other  CNMs,  then 

The  PC.Wl  sends  a  "check  if  user  is  still  logged  on"  request  to  each  of  the  other 
CNMs  in  sequence  to  determine  if  the  user  is  logged  onto  any  other  CNM's  FAWs. 

If  the  user  is  not  logged  onto  the  system,  then 
The  PCNM  transmits  the  results  to  the  OCNM. 

The  OCNM  saves  the  results  on  a  non-volatile,  random  access  medium  for 
later  use. 

Else 

The  PCNM  transmits  an  "asynchronous  event"  message  to  the  CNM  which 
is  attached  to  the  NFAW  the  user  is  logged  onto. 

That  CNM  then  transmits  the  message  to  the  user's  NFAW  . 

Endif 

Else  [the  communications  links  between  the  CNMs  not  working] 

The  PCNM  saves  the  results  on  non-volatile,  random  access  medium  for  later  use. 
Endif 

Else  [communications  link  between  the  PCNM  and  the  OCNM  not  working] 

If  the  user  is  logged  onto  any  of  the  PCNM's  FAVls,  then 
The  PCNM  transmits  the  results  to  the  user's  NFAW  . 

Else 

The  PCNM  saves  the  results  on  non-volatile,  random  access  medium  for  later  use. 
Endif 
Endif 
Endif 

If  the  user  is  logged  onto  any  FAWs  when  his/her  request  completes,  then 

The  ACNM  transmits  the  results  to  the  user's  FAW  regardless  of  whether  the  user 
IS  logged  onto  the  OFAW  from  which  the  request  was  made,  or  a  NF  AW  . 

Endif 

The  PCNM  must  transmit  to  each  attached  FA  and  all  other  CNMs  its  available  CPU/ 
processing  capability.  This  capability  is  used  by: 

(1)  The  FAWs  to  determine  if  a  CNM  can  handle  a  request  faster,  and 

(2)  The  CNMs  to  determine  which  CNM  can  handle  a  request  faster. 


Acronym  Definitions 

•\CNM  -  the  CNM  directly  attached  to  the  user's  FAW 
AF.-\W  -  all  functional  area  workstations  attached  to  an  ■XC.'NM 
('NM  -  central  node  module/manager 


TABLE  3-3b 


FAW 

MMI 

NCNM 

NFAW 
OC  NM 
OF  A  VI 
PCNM 


DESCRIPTION  OF  DATA  FLOW 
FOR 

DATA  RETRIEVAL  TRANSACTIONS 
(Central  Node  Manager)  (Continued) 


-  functional  area  workstation 

-  man-machine  interface 

-  CNM  that  the  user  is  newly  attached  to  (assuming  he  logged  off  while  his 

request  was  being  processed) 

-  newly  logged-onto  FAW 

-  original  CNM  that  received  a  FAW  request 

-  original  FAW  that  made  a  request 

-  the  CNM  that  actually  performed  the  FAW  request 


TABLE  3-4a 

DESCRIPTION  OF  DATA  FLOW 
FOR 

DATA  UPDATE  TRANSACTIONS 
(Functional  Area  Workstation) 


After  reviewing  the  retrieved  data,  the  user  updates  a  record. 

The  editor  does  not  allow  the  user  to  change  any  field  that  he/she  does  not  have  privilege  for. 

The  OFAW  sends  the  updated  record  (including  its  keys)  to  the  ACNM. 

The  OFAW  also  updates  Its  local  database.  A  copy  of  the  "before"  and  "after"  database 

record  images  is  saved  in  case  the  update  must  be  backed  out. 

[Note:  The  user  is  not  prevented  from  making  further  requests  of  AFIRMS  at  this  point.  All 
messages  from  the  ACNM  occur  asynchronously.  The  user  is  notified  each  time 
asynchronous  messages  occur.  At  that  point,  he/she  can  request  a  display  containing  a  list 
of  all  asynchronous  events  pertaining  to  him/her.  This  display  is  a  temporary  "window" 
which  is  used  only  for  viewing  any  asynchronous  events.  It  cannot  be  used  for  any  screen 
which  can  be  requested  via  the  normal  screen  selection  list.  This  window  can  also  be  looked 
at  via  the  normal  screen  selection  list.  Viewing  of  this  screen  does  not  in  any  way  destroy 
the  state  of  the  screen  the  user  was  viewing  prior  to  looking  at  the  window.  That  is,  after 
the  user  has  completed  viewing  the  window,  the  next  screen  seen  is  the  one  the  user  was 
viewing  at  the  time  he/she  requested  to  look  at  the  window,  restored  to  its  original  state.] 

For  all  other  FA'^  s  receiving  the  changed  information  from  their  ACNM, 

The  local  database  is  updated  with  the  changed  information. 

If  the  user  is  currently  looking  at  the  changed  information,  then 
The  FAW  indicates  to  the  user  that  a  change  has  occurred. 

The  user  can  then  look  at  the  screen  via  a  window  that  contains  all 
asynchronous  events,  if  desired. 

Endif 

Endfor 

If  the  OFAVi  receives  a  security  violation  message  from  the  ACNM,  then 

The  OFAW  logically  locks  the  terminal  from  further  use  by  saving  the  information  on 
the  disk  and  indicating  that  state. 

The  OFAW  generates  a  siren-like  sound  indicating  the  security  violation. 

The  OFAW  displays  the  security  violation  screen. 

The  OFAW  backs  out  the  update  that  was  attempted. 

The  OFAW'  deletes  the  "before"  and  "after"  database  record  images. 

Elseif  the  OFAW  cannot  send  a  message  to  its  ACNM  because  of  communications 

problems,  then 

The  OFAW  backs  out  the  update  that  was  made  previously. 

The  OFAW  deletes  the  "before"  and  "after"  database  record  images. 

The  OFAW'  allows  the  user  to  continue  making  other  requests. 

Elseif  the  OFAW  receives  a  processing  error  message  from  the  ACNM,  then 

The  ACNM  saves  the  update  information  on  non-volatile  random  access  medium  for 
later  use  in  attempting  to  update  the  cental  database. 

The  OFAW  deletes  the  before  and  after  database  record  images. 

Endif 
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TABLE  3-4a 


DESCRIPTION  OF  DATA  FLOW 
FOR 

DATA  UPDATE  TRANSACTIONS 
(Functional  Area  Workstation) 


Acronym  Definitions 


ACNM 

AFAW 

CNM 

FAW 

\nii 

NCNM 

NFAVi 
OCNM 
OF  AW 
PCNM 


-  the  CNM  directly  attached  to  the  user's  FAW' 

-  all  functional  area  workstations  attached  to  an  ACNM 

-  central  node  module/manager 

-  functional  area  workstation 

-  man-machine  interface 

-  NM  that  the  user  is  newly  attached  to  (assuming  he  logged  off  while  his 
request  was  being  processed) 

-  newly  logged-onto  FAW 

-  original  CNM  that  received  a  FAW  request 

-  original  FAW'  that  made  a  request 

-  the  CNM  that  actually  performed  the  FAW  request 
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TABLE  J-t^b 


DESCRIPTION  OF  DATA  FLOW 
FOR 

DATA  UPDATE  TRANSACTIONS 
(Central  Node  Manager) 


The  ACNM  receives  an  OF  AW  update  request. 

[The  OCNM  determines  whether  the  update  request  should  be  processed  immediately 
or  not.] 

If  there  are  other  update  requests  in  the  update  queue,  then 

The  update  request  is  queued  at  the  end  of  the  update  queue. 

As  update  requests  are  completed,  the  request  that  is  at  the  top  of  the  update  queue 
is  performed. 

Endif 

[The  OCNM  performs  a  security  check  to  make  sure  the  user  is  allowed  to  make  the 
update  to  the  database.] 

If  the  user  is  not  allowed  to  make  the  update  [a  security  violation  has  occurred]  then 
The  OCNM  informs  the  FAW  of  the  problem. 

The  OCNM  notifies  the  security  officer  via  three  ways: 

(1)  Sends  a  message  directly  to  his/her  terminal  if  he/she  is  logged  on. 

(2)  Sends  a  security  message  to  his/her  mailbox. 

(3)  Sends  the  security  message  to  the  system  manager's  hardcopy  device. 

Else  [the  user  is  allowed  to  make  the  update] 

The  OCNM  attempts  to  update  the  central  database. 

If  the  user  making  the  update  request  is  still  logged  onto  the  OFAW,  then 
The  OCNM  sends  the  update  status  back  to  the  OFAW'. 

Else 

The  OCNM  saves  the  update  status  on  non-volatile  random  access  medium  for 
later  use. 

Endif 

[The  OCNM  determines  whether  other  CNMs  need  that  update  information.] 

If  other  CNMs  need  the  update  information,  then 

It  is  sent  to  them.  In  addition  to  the  changed  information,  the  time/date  of  the 
update,  as  well  as  the  username  of  the  person  that  made  the  change,  are  sent. 

Endif 

All  CNMs  that  receive  updated  information  must  send  those  changes  to  each  of  their 
AFAW’s  that  currently  have  a  local  database  containing  that  record. 

[Data  consistency  checks  are  made.] 

If  other  data  within  the  central  database  is  inconsistent  with  the  newly  updated 
information,  then 

That  data  is  made  consistent  by: 

(1)  intelligent  software,  or 

(2)  requesting  the  user  to  make  other  information  consistent;  otherwise  the  original 
change  is  backed  out  and  all  FAW's  originally  receiving  that  change  are  notified. 

Endif 

Endif 
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TABLE  3-4b 

DESCRIPTION  OF  DATA  FLOW 
FOR 

DATA  UPDATE  TRANSACTIONS 
(Central  Node  Manager)  (Continued) 


Acronym  Definitions 


ACNM 

AFAW 

CNM 

FAW 

MMl 

NCNM 


NFAW 
OCNM 
OF  AW 
PCNM 


-  the  CNM  directly  attached  to  the  user's  FAW 

-  all  functional  area  workstations  attached  to  an  ACNM 

-  central  node  module/manager 

-  functional  area  workstation 

-  man-machine  interface 

-  NM  that  the  user  is  newly  attached  to  (assuming  he  logged  off  while 
request  was  being  processed) 

-  newly  logged-onto  FAW 

-  original  CNM  that  received  a  FAW  request 

-  original  FAW  that  made  a  request 

-  the  CNM  that  actually  performed  the  FAW  request 


Si 
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Table  3-5 


CNM  DATA  RETRIEVAL  REQUEST  INTERFACE  SPECIFICATION 

C.W'  Data  Retrieval  Request  Date:  31-\lay-19S5 

Interface  Specification 


The  CNM  Data  Retrieval  Request  buffer  layout  is  as  follows 


Screen  number  requested  3 

Number  of  parameters  to  follow  2 

Parameter  number  2 

Parameter  selection  number  2 

Length  of  parameter  value  3 

Parameter  value  ? 


Note:  (I)  each  field  whose  length  is  represents  a  variable  length  field.  Only 
these  fields  are  preceded  by  a  2-byte  length  descriptor  field. 


Table  3-6 


CNM  DATA  UPDATE  REQUEST  INTERFACE  SPECIFICATION 


CN.\1  Update  Request  Interface  Specification  Date:  31-May-1985 


The  CNM  Update  Request  buffer  layout  is  as  follows: 


screen  // 
for  update 


t - Repeats  for  the  number  of  keys  for  this  screen 


column  // 

length  of 

key 

for  screen 

key  value 

value 

f— Repeats  // of  changes  to  follow  I  times 


U  of  changes 
to  follow 


column  U  for 

length  of 

new 

screen  to  modify 

new  value 

value 

Field  Nanne _  Field  Length 


Screen  //  for  update  3 

Column  //  for  screen  2 

Length  of  key  value  2 

Key  value  2 

//  of  changes  to  follow  3 

Column  //  for  screen  to  modify  2 

Length  of  new  value  2 

New  value  2 


Note:  Each  field  whose  length  is  "2",  represents  a  variable  length  field.  Only 
fields  are  preceded  by  a  2'byte  length  descriptor  field. 


these 
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(2)  Remote  Terminal  Area(s).  Physical  security  measures  at  remote  sites 
must  fulfill  the  minimum  requirements  for  the  highest  classification  of 
information  accessed  from  or  stored  at  the  site. 

Hardware  Security.  AFIRMS  system  hardware  meets  all  of  the  provisions 
recommended  in  DoD  5200.28M,  ADP  Security  Manual  for  hardware  security 
features. 

Software  Security.  The  operating  systems  selected  for  use  meets  the  general 
software  security  requirements  stated  in  DoD  5200.28M.  In  addition  to  the 
security  protection  features  contained  in  the  operating  systems,  a  combination 
of  system  and  application  software  protection  features  are  utilized  to  provide 
the  following  security  protection  to  comply  with  applicable  DoD  and  Air  Force 
security  policies. 

(1)  Access  Control  to  prevent  unauthorized  entry  to  systems,  files  and 
programs. 

(2)  File  Security  to  prevent  unauthorized  access  or  alterations  to  files. 

(3)  Error  Surveillance  and  Alerts  to  recognize,  record  and  indicate  misuse  of 
the  system. 

(U)  File  Security  to  prevent  unauthorized  access  or  alterations  to  files.  An 
automated  audit  trail  will  show:  access  made  to  files;  how,  and  from 
where  the  access  was  initiated;  the  identity  of  the  person  or  process  that 
initiated  the  access;  and  all  unauthorized  attempts. 

(5)  User  Monitoring  and  Isolation  to  ensure  the  user  has  access  to  only  the 
system  information  to  which  he  is  entitled. 

System  Stability.  All  AFIRMS  components  operate  so  that  one  can 
automatically  or  administratively  detect  and  report  system  hardware  and 
software  malfunctions  in  time  to  prevent  unauthorized  disclosure. 

Data  Integrity.  Each  database,  file,  and  data  set/element  is  identified  with  an 
origin,  use,  and  an  explicitly  defined  set  of  access  controls.  These  access 
controls  are  based  on  classification,  sensitivity,  user  clearance,  and  established 
need-to-know. 

National  Bureau  of  Standards  (NBS)  or  National  Security  Agency  (NSA) 
approved  data  encryption  devices  may  be  required  for  transmission  of  sensitive 
unclassified  data  depending  on  the  nature  of  the  data. 

Emanations  Security  (EMSEC).  ADP  and  communications  equipment  utilized  to 
process  classified  material  at  AFIRMS  sites  are  TEMPEST  approved.  All 
devices  that  are  not  TEMPEST  approved  are  tested  and  approved  for  placement 
in  the  ADP  facilities  in  such  a  manner  as  to  control  compromising  emanations. 
All  equipment  is  installed  lAW  the  guidelines  stated  in  NACSIM  5203. 


i.  Procedural  Security.  Security  operating  procedures  meet  the  requirements  of 
APR  205-1  and  205-16  and  include  the  following: 

(1)  System  Access  Controls 

(2)  File  Access  Controls 

(3)  Personnel  Access  Controls 

(4)  Security  Markings 

(5)  Protecting  Classified  Output 

(6)  Physical  Security 

(7)  Protection  of  Residual  Information 

(8)  Declassification  Guidelines 

3.5  Controls.  The  AFIRMS  HQ  USAF  subsystem  requires  integrated  control  functions 
which  operate  at  system  levels  independent  of  stated  AFIRMS  operational  functionality. 
These  functions  are  implemented  and  utilized  so  as  to  minimize  their  impact  on  AFIRMS 
execution. 

Control  functions  are  logically  separated  into  two  functional  categories; 
System/Operations  Management  Controls,  and  Intrasite  Access  and  Data  Flow  Controls. 

3.5.1  System/Operations  Management  Controls.  These  controls  incorporate  the  following 
functions: 


a.  The  application  of  software  monitoring  and  diagnostic  utilities. 

b.  The  application  of  hardware  monitoring  and  diagnostic  utilities. 

c.  The  ability  to  start,  stop,  and  restart  AFIRMS  system  and  communications 
processes,  including  upper-level  control  of  network  performance. 

d.  The  ability  to  alter  AFIRMS  subsystem  runtime  parameters  dynamically  (e.g., 
process  priorities,  operating  system  parameters,  etc.) 

3.5.2  Intrasite  Access  and  Data  Flow  Controls.  These  functions  address  control 
requirements  imposed  by  security  and  data  integrity  issues.  They  also  assist  in  supporting 
downgraded  operational  modes.  These  functions  include: 

a.  Dynamic  imposition  of  limitations/new  priorities  on  intrasite  data 
communications  to  and/or  from  specific  functional  areas. 


b. 


Dynamic  limitations/alterations  of  data  access  and/or  data  modification 
authorizations  for  specific  functional  areas. 
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.  SECTION  4.  DESIGN  DETAILS 

4.1  General  Operating  Procedures.  After  AFIRMS  is  installed,  user/operator  manuals 
guide  system  operation.  The  user/operator  manuals  contain  instructions  on  how  to  turn 
equipment  on  and  off,  as  well  as  clear,  concise  instructions  for  the  operation  of  AFIRMS. 
Operating  procedures  for  both  the  system  software,  hardware,  and  functional  products  are 
provided  as  a  combination  of  vendor-provided  documents  and  AFIRMS  user  manuals.  The 
vendor-supplied  documents  detail  hardware  and  system  software  procedures  while 
AFIRMS  user  manuals  detail  functional  product  procedures  including  communications  and 
security.  The  manuals  are  written  in  sufficient  detail  to  enable  the  system  user  to 
respond  to  most  situations  he/she  may  encounter.  The  specific  requirements  for  AFIRMS 
user/operator  manuals  are  determined  during  the  in-depth  analysis  that  precedes 
implementation  at  each  AFIRMS  site. 

4.1.1  System  Start,  Restart,  and  Stop  Times.  Maximum  system  start,  restart,  and  stop 
times  are  provided  below.  AFIRMS  hardware  must  accommodate  these  times.  All 
specified  times  are  non-data  communications  related;  i.e.,  they  do  not  include  the  amount 
of  time  that  may  be  required  to  transfer  additional  required  data  from  the  CNM  to  the  FA 
upon  system  startup.  Data  communications  times  are  dependent  upon  the  data 
distributions  at  each  AFIRMS  site.  These  times  presume  a  booted  and  ready  Central 
Processing  Unit  Central  Processing  Unit  (CPU);  that  is  to  say,  times  exclude  host  machine 
power  up  and  initial  bootstrap. 


System  Start 
System  Restart* 
System  Stop  (Down) 


Central  Node 

60  seconds 
120  seconds 
120  seconds 


Functional  Area 

1 20  seconds 
240  seconds 
240  seconds 


*  Precise  definition  and  features  of  the  System  Restart  shall  be  reviewed  and 
determined  during  the  analysis  phase  that  precedes  implementation  at  each  site. 


4.2  HQ  USAF  Subsystem  Logical  Flow.  AFIRMS  logical  and  intrasite  information  flow  is 
shown  in  Figures  4-1  and  4-2,  respectively.  Squadrons  are  linked  hierarchically  to  a  wing, 
which  IS  linked  hierarchically  to  a  MAJCOM,  which  in  turn  is  linked  to  HC  USAF. 
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4.3  Subsystem  Data.  The  HQ  USAF  site  operates  on  the  following  types  of  data: 

a.  Tasking  Data.  Tasking  data  consists  of;  Vt  MPs,  OPlans/OPOR  Ds,  and  special  ad 
hoc  taskings  from  the  Secretary  of  the  Air  Force  and  the  Chief  of  Staff. 

b.  Resource  Data.  Resource  data  is  data  collected  and  maintained  by  the  wing 
squadrons  and  consists  of  aircraft  status,  aircrew  status,  fuels  status,  munitions 
status,  and  (for  later  implementation  blocks)  logistics  support  status. 

c.  Theatre  resource  data  such  as  depot  level  fuels  and  munitions,  is  maintained 
and  provided  by  depots  and  support  units  via  automated  systems  such  as  CAS, 
CF.MS,  etc. 
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4.3.1  Inputs. 

a.  The  following  input  data  is  provided  to  the  HQ  USAF  subsystem: 

(1)  Outyear  resource  information  (for  POM,  exercises) 

(2)  Ad  hoc  and  small  contingency  tasking  information  (i.e.,  close-hold) 

b.  Input  Records.  Input  record  nomenclature,  source,  expected  volume,  frequency, 
priority,  degree  of  sensitivity  and  requirement  for  timeliness  are  described  in 
the  AFIR.MS  Product  Descriptions  Document.  Interface  specifications 
corresponding  to  input  record  requirements  are  provided  in  Table  3-5  of  this 
subsystem  specification.  The  transaction  header  interface  specification 
detailed  in  Appendix  A  contains  information  to  discriminate  between  input 
records  and  input  data  element  transactions. 


c.  Input  Data  Elements,  Data  elements  for  each  input  record  type  are  described  in  the 
AFIRMS  Database  Specifications  and  the  Data  Requirements  Document.  Interface 
specifications  corresponding  to  input  data  element  requirements  are  provided  in 
Table  3-5  and  Appendix  B  of  this  subsystem  specification.  The  transaction  header 
interface  specification  detailed  in  Appendix  A  contains  information  to  discriminate 
between  input  records  and  input  data  element  transactions. 


4.3.2  Outputs.  Operational  AFIRMS  outputs  include  reports  and  graphic  readiness 
measurement  displays  as  follows: 


a.  Output  Reports.  All  AFIRMS  output  reports  can  be  displayed  on  the  user's 
terminal  or  printed  as  hardcopy.  There  are  no  requirements  for  preprinted 
forms  for  generation  of  hardcopies. 
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Table  4-1  provides  information  concerning  the  format,  complexity,  security 
classification,  and  estimated  daily  volume  and  frequency  of  AFIRMS  output 
reports.  For  response  times  of  these  AFIRMS  output  reports,  reference  Section 
2.2.3  of  this  subsystem  specification,  in  which  AFIRMS  query  response  times 
are  provided  for  varying  degrees  of  query  complexity. 

Table  4-2  details  the  primary  and  secondary  functional  area  users  of  AFIRMS 
output  reports.  In  addition,  these  outputs  are  fully  described  in  the  AFIRMS 
Product  [descriptions  series. 


Screen  Title 

Format 

Estimated 
Daily  Volume 
and  Frequency 

Complexity 

Security 

Classifi¬ 

cation 

Aircraft  &  Mission  Tasking  Details 

Tabular 

1  pg  (§12 

Medium 

U-TS* 

Aircraft  Spares  Support  Capability 

Graphic 

1  pg  §20 

Complex 

U-TS* 

Aircraft  Tasking 

Graphic 

1  pg  §12 

Medium 

U-TS* 

Attrition  Statistics 

Tabular 

2  pg  §16 

Simple 

Secret 

Attrition  Trends 

Graphic 

1  pg  (38 

Simple 

Secret 

Base  Fuels  Capability 

Graphic 

1  pg  §20 

Medium 

U-TS* 

Base  Status  (Input) 

Tabular 

8  pg  §16 

Simple 

U-S 

Base  Status  (Output) 

Graphic 

8  pg  §16 

Simple 

U-S 

Capability  Perspective 

Graphic 

1  pg  §2 

Complex 

Secret 

Communications  Support  Status 

Graphic 

8  pg  §24 

Simple 

U-S 

Dollars  to  Readiness  -  Comparisons 

Graphic 

1  pg  (38 

Complex 

U-S 

Dollars  to  Readiness  -  Resource 
Perspective 

Graphic 

1  pg  §2 

Complex 

U-S 

Fuels  Capability 

Graphic 

1  pg  §20 

Medium 

U-TS* 

Individual  Resource  Capability 

Graphic 

1  pg  @12 

Complex 

U-TS* 

Integrated  Capability 

Graphic 

1  pg  @12 

Complex 

U-TS* 

MICAP  Forecast 

Tabular 

8  pg  @16 

Medium 

Unclass 

Mission  Area  Tasking 

Graphic 

1  pg  @4 

Medium 

Secret 

Mission  Profile  Definition 

Tabular 

8  pg  @16 

Simple 

U-S 

Mission  Tasking 

Graphic 

1  pg  @12 

Medium 

U-TS* 

Munitions  Capability 

Graphic 

1  pg  @20 

Medium 

U-TS* 

Munitions  Status 

Tabular 

8  pg  §48 

Medium 

U-S 

Munitions  Substitution  Sortie 
Capability 

Graphic 

1  pg  (34 

Complex 

Secret 

Munitions  Substitution  Sortie 
Requirement 

Graphic 

1  pg  134 

Complex 

Secret 

OPlan/OPORD  Associations 

Tabular 

3  pg  §8 

Simple 

Unclass 

Order  Assignments 

Tabular 

8  pg  @8 

Simple 

U-S 

Process  Status 

Tabular 

3  pg  §20 

Simple 

Unclass 

Resource  Reallocation 

Graphic 

1  pg  @8 

Simple 

Secret 

Resource  Unit  Price 

Tabular 

3  pg  @4 

Simple 

Unclass 

Status  Map 

Graphic 

3  pg  §20 

Simple 

U-S 

Unit  Status  (Input) 

Tabular 

8  pg  §16 

Medium 

U-S 

Unit  Status  (Output) 

Tabular 

8  pg  §16 

Medium 

U-S 

War  Mobilization  Plan 

Tabular 

2  pg  §4 

Simple 

Secret 

Uing  Flying  Day 

Tabular 

3  pg  @4 

Simple 

U-S 

Wing  Operations  Rates 

Tabular 

3  pg  @4 

Simple 

U-S 

Wing  Resource  Summary 

Tabular 

20  pg  38 

Medium 

U-S 

Wing  Resupply  Schedule 

Tabular 

20  pg  34 

Simple 

U-S 

CDRL  0027 


4-5/CHG  1 


fTi 


s's~v 


*Some  classifications  have  a  range,  i.e.,  U-TS,  meaning  Unclassified  through 
Top  Secret.  That  range  normally  results  from  a  variable  tasking 
classification  (e.g.,  some  tasks  are  Unclassified,  some  are  Confidential,  some 
are  Secret,  etc.) 

Note  1;  Depending  on  input  parameters,  some  times  will  increase/decrease 

depending  on  the  amount  of  data  retrieved.  For  example,  requesting 
Munitions  Capability  for  60  days  doubles  the  amount  of  data  and  time 
over  a  30  day  parameter  input  and  increases  the  data  retrieval  time. 

Note  2:  1  pg  @  1  denotes  that  the  average  screen  length  (volume)  is  one 

page,  and  it  is  accessed  once  daily. 


AFIRMS  OUTPUT  REPORTS  BY  FUNCTIONAL  AREA  USERS 


Screen  Title 

Primary  User(s) 

Supporting  User(s) 

Aircraft  Tasking 

CSS,  XOXIC 

XOXFM,  XOOIR, 
XOXR(MAA) 

Base  Fuels  Capability 

LRC,  LEYS 

CSS,  XOOIR/LERX 

Base  Status  Map 

CSS 

LRC 

Base  Status  (I/O) 

LRC,CSS,X00IM, PRC 

XOOOA/XOOOE 

Base  Status  (Output) 

LRC.CSS.XOOIM.PRC 

XOOOA/XOOOE 

Capability  Perspective 

XOOIM 

Dollars  to  Readiness  -  Associations 
Dollars  to  Readiness  -  Comparisons 

PRP 

LEXX,  LEXY,  LEYS 

(All  Resources) 

PRP 

LEXX,  LEXY,  LEYS 

Dollars  to  Readiness  -  Comparisons 

(Fuels) 

PRP 

LEXX,  LEXY,  LEYS 

Dollars  to  Readiness  -  Resource 

PRP 

LEXX,  LEXY,  LEYS 

Perspective 

Fuels  Capability 

LRC,  CSS 

LEYS.  XOOIR/LERX 
XOXR(MAA) 

Individual  Resource  Capability 

LRC,  CSS 

LEYS.  LEXY,  LEXX, 
XOOIM  XOOIR/LERX 
XOOIC,  XOXR(MAA) 

Integrated  Capability 

LRC,  CSS 

XOOIM,  XOOIR/LERX, 
XOXIC,  XOXR(MAA) 

Order  Assignments 

CSS 

XOXIC 

Munitions  Status 

LRC 

LEYW,  CSS 

Munitions  Capability 

LRC 

XOXR  (MAA),  CSS, 
XOXFM,  LEYW, 
XOOIR/LERX 

Mission  Profile  Definition 

XOXIC,  CSS 

OPlan/OPORD  Associations 

LEXX,  LRC,  LEYS, 

LEXY,  XOOIM.  CSS. 
XOXIC 

Process  Status 

LEXX,  LRC,  LEYS, 

LEXY,  XOOIM,  CSS, 
PRP,  XOXIC 

Resource  Reallocation 

LRC 

CSS 

Resource  Unit  Price 

PRP 

LEYS.  LEYW 

Resupply  Schedule 

LEXX.  LEYS.  LEYW. 

LRC 

CSS 

Unit  Status  (Output) 

CSS,  LRC.  XOIUM 

Unit  Status  (I/O) 

CSS.  LRC.  XdDiM 

War  Mobilization  Plan 

CSS.  XOoIM.  X'lXl!' 

LRC.  XdXFM. 

XllXR(  Mnn  ) 

wing  Flying  Da;/ 

CSS 

Xo(H Xii''i'E.  Xi'XP, 
X'lXIf.  XiioIM 
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Table  4-2 

AFIRMS  OUTPUT  REPORTS  BY  FUNCTIONAL  AREA  USERS  (Continued) 


Screen  Title 

Primary  User(s) 

Supporting  User(s) 

Wing  Operations  Rates 

CSS 

XOOOA/XOOOE,  XOXP, 

LRC,  XOXIC,  XOOIM 

Wing  Resource  Summary  (0) 

LRC 

LEYV,  LEYS 

Uing  Resource  Summary  (I/O) 

LRC 

LEYU,  LEYS,  CSS 

Resource  Rollup 

LRC,  XOOIM 

XOOOA/XOOOE 

Run  $-Readiness 

PRP 

Run  SGM 

XOOIM,  LRC,  LEYS. 

XOXIC, 

LEXY,  LEXX,  CSS 

XOOIR/LERX, 

XOXR(MAA) 

Table  4-2 


AFIRMS  OUTPUT  REPORTS  BY  FUNCTIONAL  AREA  USERS  (Continued) 


Screen  Title  (Unimplefflented) 

Primary  User(s) 

Supporting  User(s) 

Aircraft  Spares  Support  Capability 

LEXY,  LEYS 

LRC 

Attrition  Trends 

PRC,  CSS 

Communications  Support  Status 

XOOOA/XOOOE, CSS 

Fuel  Status  Map 

LRC 

CSS 

Individual  Resource  Capability 

LEYS,  LEYV 

PRP 

Mission  Area  Tasking 

Mission  &  Aircraft  Tasking  Detail 

PRPF,  XOXIC 

Summary 

XOXIC 

PRPF 

Mission  Tasking 

Munitions  Substitution  Sortie 

XOXIC 

PRPF 

Capability 

XOXFM 

LEYV,  PRP, 

XOXR (MAA) 

Munitions  Substitution  Sortie 

Requirement 

XOXFM 

LEYV,  PRP, 

XOXR (MAA) 

ABBREVIATIONS/ACRONYMS/AIR  FORCE  CODES 


CSS 

LEXX 

LEXY 

LEYS 

LEYV 

LRC 

PRC 

PRPF/R 

XOOOA/XOOOE 

XOOIM 

XOOIR/LERX 
XOXFM 
XOXIC 
XOXR  (MAA) 
XOXP 


Contingency  Support  Staff 

Logistics  Plans  Division 

Logistics  Concepts  Division 

Supply  Policy  and  Energy  Management  Division 

Munitions  and  Missiles  Division 

Logistics  Readiness  Center 

Personnel  Readiness  Center 

Programs  &  Evaluation  Directorate  (Forces  &  Resources) 

Air  Force  Operations  Center/Contingency  Support  &  Exercise 
Branch 

Readiness  Assessment  Group 

CHECKMATE  Group 

Munitions  Planning  Division 

War  &  Mobilization  Planning  Division 

Capability  Assessment  Division 

Assistant  Director  for  Special  Plans 
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b.  Output  Data  Elements.  Output  data  elements  are  described  in  the  AFIRMS 
Database  Specifications;  the  corresponding  interface  specifications  are 
provided  in  Appendix  B  of  this  subsystem  specification. 

4.3.3  Database  Description.  For  detailed  AFIRMS  database  requirements,  reference  the 
AFIRMS  HQ  USAF  Database  Specification. 

a.  Database  Identification.  The  label  by  which  the  HQ  USAF  database  is  uniquely 
identified  is  "HQUSAFDB.”  The  HQ  USAF  subsystem  maintains  databases  as  follows: 

(1)  Real:  This  database  contains  peacetime  and  crisis  tasking,  and  other  day-to-day 
operational  data. 

(2)  What  If:  This  physical  database  is  comprised  of  three  types  of  logical  databases: 

(a)  Exercise  -  This  database  contains  data  which  provides  a 

simulation  of  an  actual  crisis. 

(b)  Ad-Hoc  What  If  -  This  database  contains  data  which  provides  a 

simulation  of  a  hypothetical  crisis  or  situation. 

(c)  Historical  -  This  database  contains  data  which  provides  a 

historical  view  of  the  real,  exercise,  or  ad-hoc 
what  if  databases. 

b.  Storage.  The  master  fiMs)  containing  the  HQ  USAF  database  will  be  stored 
on-line  on  mass-storage  disk  devices  and  off-line  on  magnetic  tape  and  formatted 
floppy/microfloppy  disk. 

c.  Database  Query  Capabilities.  The  design  of  the  AFIRMS  database  supports  the 
requirements  for  an  interactive  query  capability  accessing  current  and/or  what-if 
data  for  the  above-named  databases.  Historical  data  resides  primarily  on  off-line 
media  and  is  copied  to  on-line  media  on  an  "as-needed"  basis. 

(1)  Ad-Hoc  Querying.  Selected  users  may  execute  ad  hoc  queries  against  any 
on-line  databases  to  which  they  are  permitted  access.  Ad  hoc  querying  is 
constrained  by  AFIRMS  security  and  control  requirements.  This  capability  is 
limited  to  databases  located  at  the  functional  area  and  the  central  location 
within  a  site.  Controls  within  the  DBMS  and  security  software  are  used  to 
limit  access  to  both  the  functional  area  and  central  database  on  a 
user-by-user  basis. 

Ad  hoc  query  access  is  provided  by  the  AFIRMS  executive.  The  user  has  the 
ability  to  interactively  query  the  database  via  an  "English-like"  AFIRMS 
query  utility.  The  user  does  not  have  the  ability  to  update  any  data  while  in 
this  mode.  Ad  hoc  queries  are  limited  to  current  or  crisis  mode  data  only. 

When  data  is  requested,  if  it  is  not  present  in  the  local  functional  area 
database,  the  request  is  transmitted  to  the  central  node.  The  request  is  then 
processed  at  the  central  node  and  the  results  returned  to  the  requesting 
functional  area  for  display.  There  is  no  capability  for  ad-hoc  querying  across 
sites  within  AFIRMS. 
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(2)  What-If  Capability.  A  what-if  capability  exists  in  AFIRMS  to  enable  certain 
users  to  input  hypothetical  tasking,  resource,  or  operations  scenarios  to 
better  predict  future  readiness  capability.  The  data  is  input  into  the  local 
database  through  a  highly  structured  AFIRMS  environment.  The  what-if 
capability  of  AFIRMS  directly  affects  the  amount  of  data  redundancy 
necessary  at  each  site  and,  accordingly,  the  amount  of  physical  storage 
capacity  necessary  to  handle  it.  What-if  data  storage  needs  vary  according 
to  the  level  in  the  command  structure  and  the  functional  users'  what-if 
exercise  needs. 

Database  Backup,  Restoration,  and  Archiving.  Backup  of  the  database  to  off-line 
media  occurs  on  a  daily,  weekly,  monthly,  and  yearly  basis;  each  backup  is 
maintained  for  a  different  length  of  time: 

(1)  Daily  Database  Backups.  Daily  backups  are  maintained  for  five  working  days. 

(2)  Weekly  Database  Backups.  Weekly  backups  are  maintained  for  five  weeks. 

(3)  Monthly  Database  Backups.  Monthly  backups  are  maintained  for  12  months. 

(4)  Yearly  Database  Backups.  Yearly  backups  are  maintained  for  five  years. 

Restoration  occurs  in  the  event  that  data  in  the  database  has  been  lost  or 
damaged.  Whenever  a  transaction  occurs  in  the  local  database,  it  will  be  logged  to 
a  journal  file  for  use  in  the  event  restoration  is  needed.  Restoration  consists  of 
reloading  the  latest  copy  of  the  database  from  off-line  media,  if  necessary,  and 
applying  the  journal  log  file  to  it. 

Archiving  of  data  to  tape  or  disk  is  accomplished  as  required  by  AFIRMS  users. 

Database  Size.  It  is  estimated  that  the  size  of  all  the  files  contained  in  the  HQ 
USAF  database  is  a  total  of  approximately  300  megabytes.  This  figure  is  based 
upon  AFIRMS  implementation  at  all  Air  Force  MAJCOMs,  and  is  the  total  of  all 
below-listed  MA3COM  databases.  See  the  HQ  USAF  Database  Specification  for 
details  on  the  HQ  USAF  database  sizing  estimations. 

Database  Elements.  AFIRMS  HQ  USAF  database  elements  are  described  in  the 
AFIRMS  HQ  USAF  Database  Specification  and  Data  Requirements  Document. 


4.4  Program  Description.  This  subsystem  specification  is  to  contain,  as 
annexes,  C-level  program  specifications  which  detail  specific  requirements  for 
the  subsystem  functional  products.  The  HQ  USAF  subsystem  consists  of  programs 
for  the  following  products  (in  addition  to  systems  software): 


Screen/Process  Title 

Aircraft  &  Mission  Tasking  Details 
Aircraft  Spares  Support  Capability 
Aircraft  Tasking 
Attrition  Trends 
Base  Fuels  Capability 
Base  Status  (Input) 

Base  Status  (Output) 

Base  Status  Report 

Base/Unit  Status  Rollup 

Capability  Perspective 

Communications  Support  Status 

Dollars  to  Readiness  Associations 

Dollars  to  Readiness  -  Comparisons 

Dollars  to  Readiness  -  Resource  Perspective 

Fuels  Capability 

Individual  Resource  Capability 

Integrated  Capability 

Mission  Area  Tasking 

Mission  Profile  Definition 

Mission  Tasking 

Munitions  Capability 

Munitions  Status 

Munitions  Substitution  Sortie  Capability 

Munitions  Substitution  Sortie  Requirement 

OPlan/OPORD  Associations 

Order  Assignments 

Process  Status 

Resource  Reallocation 

Resource  Status  Rollup 

Resource  Unit  Price 

Run  Dollars  to  Readiness  Model 

Run  Sortie  Generation  Model  (SGM) 

SGM  Associations 
Status  Map 

Transmit  Base  Status 
Transmit  Resource  Status 
Transmit  Unit  Status 
Unit  Status  (Input) 

Unit  Status  (Output) 

War  Mobilization  Plan 
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Screen/Process  Title 

Wing  Flying  Day 
Wing  Operations  Rates 
Wing  Resource  Summary 
Wing  Resupply  Schedule 


For  detailed  descriptions  of  these  products,  refer  to  the  AFIRMS  Product 
Descriptions  Index  and  Document. 
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APPENDIX  A.  INTRA-SITE  TRANSACTION  HEADER 


Field  Name  Field  Description 

TRANS_ID  a.  Transaction  identifier. 

b.  Each  terminal  has  its  own  IDs. 

c.  The  legal  values  are  l->  65535.  After  65535,  it  should  rollover 
back  to  1. 

TR ANS_.VlSG_LEN  a.  Transaction  message  length. 

,  b.  The  length  is  the  sum  of  the  transaction  header  plus  data  length. 

c.  The  legal  values  are  S5-^  8192. 

REQ_REP_FLAG  a.  Request/Reply  flag. 

b.  User  interactive  display  software  always  sends  requests.  The  host 
always  sends  replies  in  response  to  the  request  as  long  as  the 
transaction  was  not  submitted  as  a  batch  job.  The  host 
occasionally  sends  unsolicited  requests  to  the  CGC  (i.e.,  update 
messages).  It  does  not  expect  a  reply. 

c.  The  legal  values  are  ”Q'*  for  request  and  "P"  for  reply. 

30B_TYFE  a.  Interactive/Batch/Network  flag. 

b.  All  jobs  must  run  interactively  if  they  expect  a  product  screen 
display.  Otherwise,  they  can  be  run  as  batch.  Note:  batch  jobs 
never  send  back  replies.  Their  status  can  be  monitored  through 
the  batch  monitor  screen. 

c.  The  legal  values  are  "1"  for  interactive,  "B"  for  batch,  and  "N"  for 
network. 

5RC_NODEJD  a.  Source  node  ID. 

b.  This  is  the  node  ID  of  the  requestor. 

SRCJTERMJD  a.  Source  terminal  ID. 

b.  This  is  the  terminal  ID  of  the  requestor. 

c.  The  legal  values  are  local  site  dependent.  Note:  the  value  1111  is 
reserved  for  host  generated  transactions  (i.e.,  unsolicated  update 
messages). 

SRC_LSER_N AWE  a.  Source  username. 

b.  This  is  the  username  of  the  requestor. 

c.  The  legal  values  are  site  dependent.  They  must  match  the 
username  used  for  logging  into  the  host. 

OSTJsODEJD  a.  Destination  node  ID. 

b.  This  field  is  filled  in  by  a  transaction  router.  It  is  the  same  as 
the  SRC_NODEjD  for  the  local  requests  that  require  a  reply.  In 
general,  it  is  always  the  node  ID  of  where  the  transaction  is 
destined.  It  differs  from  the  SRC_NODE_ID  only  for  network 
messages. 


Field  Name  Field  Description 

D5T_TER\nD  a.  Destination  terminal  ID. 

b.  This  field  is  filled  in  by  a  transaction  router.  It  is  the  same  as  the 
SRCJTERMJD  for  the  requests  that  require  a  reply.  In  general,  it 
is  the  terminal  ID  of  where  the  transaction  is  destined.  It  differs 
only  for  network  messages. 

c.  The  legal  values  are  remote  site  dependent. 

DST_LSER_\AME  a.  Destination  username. 

b.  This  field  is  filled  in  by  a  transaction  router.  It  is  the  same  as  the 
SRC_USER_NAME  for  the  requests  that  require  a  reply.  In 
general,  it  is  always  the  username  of  where  the  transaction  is 
destined. 

c.  The  legal  values  are  site  dependent.  They  must  match  the 
username  used  for  logging  into  the  host  for  local  transactions. 

For  network,  transactions,  the  username  "♦ROLLUP*"  is  reserved. 

EXP_DAT_J1M  a.  Transaction  expiration  date/time. 

b.  There  are  four  subfields: 

1.  Expiration  year 

b.  The  legal  values  are  0  99. 

2.  Expiration  day 

b.  The  legal  values  are  1  -■>  366.  Note;  366  is  only  valid  for 
leap  years. 

3.  Expiration  hour 

b.  The  legal  values  are  0  -■>  23. 

If,  Expiration  min 

b.  The  legal  values  are  0  59. 

\10D_REQ_1D  a.  Module  request  ID. 

b.  This  field  is  looked  at  only  by  the  transaction  routing  mechanism 
to  determine  whether  the  transaction  is  destined  for  the  database 
server  or  somewhere  else. 

c.  The  legal  values  are  1  2.  Their  meanings  are  as  follows: 

1  =  forward  transaction  to  the  database  router 

2  =  AFIRMS  service  request 


FUNC_REgjD 


a.  Function  request  ID. 

b.  This  field  is  looked  at  by  the  transaction  routing  mechanism  only 
when  MOD_REQJD  =  2.  It  signifies  what  AFIRMS  service  to 
perform.  Currently,  the  only  service  is  to  log  off  the  user. 

c.  The  legal  values  are  1  10.  Their  meanings  (when  MOD_REQ 

ID=1)  are  as  follows; 

1  =  organize  records  (send  transaction  /f2) 

2  -  update  record 

3  =  insert  record 

4  =  delete  record 


5  =  logoff  Database 

6  =  Edit  info  (send  transaction  //I) 

7  =  insert  continuation  record 
S  =  delete  continuation  record 
9  =  log  invalid  batch  job 
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Field  Name 


Field  Description 


\tSG_PRIO  a.  Message  priority. 

b.  This  field  is  used  by  the  process  controller  to  put  each  transaction 
it  receives  into  the  appropriate  priority  mailbox  (i.e.,  queue). 

(1)  The  transaction  router  uses  it  as  a  consistency  check  to  make 
sure  the  transaction  is  sent  to  the  right  mailbox,  and 

(2)  to  set  the  priority  of  the  Database  server  that  will  be 
processing  that  transaction,  and 

(3)  The  Database  server  uses  it  to  determine  to  which  priority 
mailbox  it  should  forward  replies. 

c.  The  legal  values  are  1  for  low  priority,  5  for  medium  priority,  and 
9  for  high  priority. 

VIMSG_STAT  a.  Message  status. 

b.  This  field  is  used  for  returning  the  status  of  a  user's  request. 

c.  The  legal  values  are  any  32-bit  number.  Note:  MSG  ST  AT  must 

be  initially  set  to  0  in  the  original  request.  ~ 

MSG_SEG_CUR  a.  Message  number  current. 

b.  This  field  is  the  current  message  segment  number.  It  is  always  1 
unless  there  is  a  multi-part  transaction  (i.e.,  one  that  must  split 
because  it  is  too  large  for  a  single  buffer). 

c.  The  legal  values  are  1  —  >255. 

MSG_SEG_TOT  a.  Message  number  total. 

b.  The  legal  values  are  I  —  >255. 
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B.l  Data  Interface  Specification  (GENEDIT)  Date;  31-May-1985 


The  AREA-C  buffer  layout  for  GENEDIT  SCREENS  is  as  follows: 


Current 

Oldest 

Latest 

As-of- 

Screen 

Time-of- 

screen 

screen 

status 

Classification 

day  DTG 

value  DTG 

value  DTG 

DTG  flag 

Repeats<(//  of  subtitles)’times 


As-of-status 

//  of 

DTG 

subtitles 

subtitle 


U  of 
records 


Repeats  Kjf  of  records)  times 


//  of  continuation 
lines 


Repeats  for  all  fields  in  a  record 


field 


Repeats  <(//  of  continuation  line^  times 
—  Repeats  for  all  fields  in  a  continuation  line 


field 


Field  name  Field  length 

Screen  classification  1 

Current  time-of-day  DTG  16 

Oldest  screen  value  DTG  16 

Latest  screen  value  DTG  16 

As-of-status  DTG  flag  1 

As-of-status  DTG  ? 

//  of  subtitles  2 

Subtitle  ? 

//  of  records  3 

//  of  continuation  lines  2 

Length  of  field  2 

Field  ? 


Note:  (1)  Each  field  whose  length  is  represents  a  variable  length  fielc.  The  lielGs 
are  preceded  with  a  2-byte  length  descriptor. 

(2)  The  number  of  fields  in  a  record  or  a  continuation  line  is  screen  specific. 
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Date:  31-May-1985 


The  AREA-C  buffer  layout  for  CAPABILITY  bCREENS  is  as  follows: 


Current 

Oldest  Latest 

As-of- 

Screen 

Time-of- 

screen  screen 

status 

Classification 

day  DTG 

value  DTG 

value  DTG 

DTG  flag 

As-of-status 

//  of 

DTG 

subtitles 

//  of 

//  of 

taskings 

days 

I —  Repeats  <// of  subtitles)>  times 


subtitle 


Repeats<//  of  taskings> times 

I — Repeats  <(//  of  days)>  times 


tasked 
item  name 


U  of 
capable 
lines  per 
tasking 


tasked 

amount 


r  Repeats  <//  of  capable  lines  per  tasking)> 

I — Repeats<//  of  days>times 


capable 

item 

name 

capable 

amount 

_ _ 

Field  Name _  Field  Length 

Screen  classification  I 

Current  time-of-day  DTG  16 

Oldest  screen  value  DTG  16 

Latest  screen  value  DTG  16 

As-of-status  DTG  flag  1 

As-of-status  DTG  ? 

//  of  subtitles  2 

Subtitle  ? 

//  of  taskings  3 

//of  days  3 

Tasked  item  name  ? 

Tasked  amiount  ? 


//  of  capable  lines  per  tasking 
Capable  item  name 
Capable  amount 


Note:  Each  field  whose  length  is  represents  a  variable  length  field.  The  fields  are 
preceded  with  a  2-byte  length  descriptor. 


B.3  Data  Interface  Specification  (MAP)  Date: 

The  AREA-C  buffer  lavout  for  MAP  SCREENS  is  as  follows: 


31-May-1985 


Current 

Oldest 

Latest 

As-of- 

Screen 

Time-of- 

screen 

screen 

status 

Classification 

day  DTG 

value  DTG 

value  DT G 

DTG  flag 

As-of-status 

DTG 


//  of 
records 


//  of 

subtitles 


Repeats^//  of  subtitlesptimes 


subtitle 


■Repeats<^//  of  records)>times 

—  Repeats  for  the  //  of  fields  in  this  screen's  record. 


Field  length 


Field  name 

Screen  classification 
Current  time-of-day  DTG 
Oldest  screen  value  DTG 
Latest  screen  value  DTG 
As-of-status  DTG  flag 
As-of-status  DTG 
//  of  subtitles 
Length  of  subtitles 
Subtitle 
//  of  records 
Length  of  field 
Field 


(1)  Each  field  whose  length  is  represents  a  variable  length  fielo.  The  fielcs 
are  preceded  with  a  2-byte  length  descriptor. 

(2)  The  number  of  fields  in  a  record  is  screen  specific. 


B.4  Data  Interface  Specification  (FORECASTS) 


Date:  31-May-1985 


The  AREA-C  buffer  layout  for  AVAILABLITY  FORECAST  SCREENS  is  as  follows: 


Expenditure 

rate 


//  of 

historical 
days  plot 


of 

days  to 
critical 


Historical 

average 

flag 


//  of 

historical 
days  avg. 


Critical 

level 


//  of 

forecast 

days 


//  of 

offbase 

locations 


Repeats<//  of  historical  days  plot)> times 


Amount 
on  hand 
(day  //X) 


//  of 
days 

remaining 


Field  Name _  Field  Length 

Screen  classification  I 

Current  time-of-day  DTG  16 

Oldest  screen  value  DTG  16 

Latest  screen  value  DTG  16 

As-of-status  DTG  flag  1 

As-of-status  DTG  ? 

//  of  subtitles  2 

Subtitle  ? 

Expenditure  rate  ? 

Historical  average  flag  1 

//  of  historical  days  avg.  3 

Critical  level  ? 

//  of  forecast  days  3 

//  of  offbase  locations  1 

//  of  historical  days  plot  3 

Amount  on-hand  (day  //1-n)  ? 

U  of  days  to  critical  3 

U  of  days  remaining  3 

Note:  Each  field  whose  length  is  represents  a  variable  length  field.  These  fields  are 
preceded  by  a  2-byte  length  descriptor  field. 
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B.3  Data  Interface  Specification  (BAR  CHART  WITH  LINES)  Date;  31-May-1984 

The  AREA-C  buffer  layout  for  BAR  CHART  WITH  LINE  SCREENS  is  as  follows: 


bcreen 

classification 


Current 

Oldest 

Latest 

Tirrie-of- 

screen 

screen 

Task  ID 

day  DTG 

value  DTG 

value  DTG 

DTF  flag 

Task-ID 

DTG 


//  of 

subtitles 


Repeats<_//  of  subtitles)>times 


ubtitles  I  j _ I  subtitle 

Repeats  of  bars)> times 


bottom 

top 

bar 

bar 

height 

height 

-  Repeats <//  of  bars>times 

//of  line 

bars  height 

Field  Name _  Field  Length 

Screen  classification  1 

Current  time-of-day  DTG  16 

Oldest  screen  value  DTG  16 

Latest  screen  value  DTG  16 

Task-ID  DTG  flag  1 

Task-ID  DTG  ? 

//  of  subtitles  2 

Subtitle  ? 

//  of  bars  3 

Bottonr  bar  height  ? 

Top  bar  height  ? 

Line  height  ? 

.ote:  Each  field  whose  length  is  represents  a  variable  length  field.  Only  these 

fields  shall  be  preceded  by  a  2-byte  length  descriptor  field. 
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B.6  Data  Interface  Specification  (BAR  CHART)  Date:  31 -May-1 984 

The  AkEA-C  buffer  layout  for  BAR  CHART  SCREENS  is  as  follows: 


#  of 
bars 


Repeats <//  of  bars>  times 


Label 

front 

rear 

front 

rear 

bar 

bar 

bar 

bar 

value 

value 

color 

color 

Field  name 

//  of  bars 
Label  for  bar 
front  bar  value 
rear  bar  value 
front  bar  color 
rear  bar  color 


Field  length 
3 

7 

7 

7 

3 

3 


Note:  Each  fielc  whose  length  is  represents  a  variable  length  field.  These  fields 
preceded  by  a  2-byte  length  descriptor  field. 
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